[REBOL] Re: using Rebol for mail client app
From: boris:garbuzov:marketingtips at: 19-Apr-2002 9:41
Thanks, Anton. Below is a project description and research materials. The
main usage is autoreplies and address harvesting. I guess, recruiters can
use it a lot. It is not an inter-organizational thing. Since your IOS
requires installation, it is not the thing to deliver the product to any
machine on the web. For instance, our paid customer can not use it this way
from the library, Internet Cafe or friend's house because owners of those
machines won't allow them to install your thing, and I guess it is pretty
technical task. But still there is a possibility to use it in a stand-alone
version? I will appreciate if you let me realize the options by discussing
the issue.
--------------------
If you use Rebol IOS you probably won't need to use
email again, internally, at least! :)
Communication is more efficiently served by the Messenger
and Conference reblets and the transparent file sharing
mechanism.
But - What will your application do?
Can you give some more details?
===================
Addition to MyMailloop Spec
1. Description
Under review is mail flow management system that is an upgrade of existing
Mailloop5.0 Windows stand-alone application. Now it will become ASP or thin
client version. Most of the processing moves to server component. The client
part is hopefully to be implemented in 2 kinds - stand-alone (initially
thought - Java1.1) and some web version (initially thought - applet). In
this initial intention applet and 1.1stand-alone version must have some
common code base. The server component is to be written in C++ by Rick and
Paul in parallel to Java client team that is not yet hired. Apparently,
stand-alone Java client is also not a final decision. For instance, Paul
votes for native code stand-alone client, because he has experience in C++
GUI (so he can do both client and server parts). The final decision may
depend on who will be hired for a client team. It can also change during
development. For instance, some semi-functional prototype may be developed
as initially intended and then reconsidered.
5. Client Part Design
5.1. W.X.'s note
If user can build socket connections with your server, applet can use the
connection to do Object or binary communication. If use is behind a
firewall, they normally can not build socket connections with servers
outside the firewall, so applet can check this, and use Servlet to transfer
information with your server.
5.2. J.S.'s note
I use the new IE, and there is no problems with supporting the Java 1.1.8,
or AWT, code. The only thing is that the Java 2 runtime is not included
with the browser and has to be downloaded and installed, and requires the
user to grant permissions to the Sun codebase, similar to Java Webstart. I
think deploying an application with Java WebStart is a secure way to build
and deploy an application of this nature. Again, the problem with useful
applets is that it is very hard to control who has access to them. For an
example, see a homepage that I am currently working on... forgive the
incompleteness, it is a work in progress, but the applets that are embedded
into the page are from two different financial sources. The example here:
http://24.82.118.183/futures/indexjava.html. The "Launch Chart" button at
the bottom of the page opens up an applet which I "borrowed" from a
financial brokerage where I have an account. This codebase is not available
to the general public, but once you become a user you have access to the
pages in which this code resides. JavaWebStart is not something that I have
used in a production situation. I have installed and tested the
applications that come with the installer package, and it works quite well.
It is a good option to consider at this conception stage. More on Java Web
Start here: http://java.sun.com/products/javawebstart/. I imagine that you
have been hearing a lot of opinions regarding the applet development issue,
and whether to use Flash or LiveConnect or something else, so I will keep my
opinion brief and to the point. First, an excerpt from this page:
http://developer.apple.com/internet/javascript/iframe.html ... Now, an
sample of this iframe remote scripting:
http://24.82.118.183/futures/index.html. In this sample, a servlet is called
by the html form without submitting the page or reloading the browser. The
servlet calls for a page from the internet, parses out the chart's image tag
from the response, and passes the image tag back to the browser. The
browser uses the document object model (DHTML) to switch the image's src
reference to the remote internet host. I thought this was really neat
solution for an internet application. Whatever you decide, I would be
interested in working with you on it. Please feel free to contact me by
email. More about the IFRAME: The IFRAME was introduced by Microsoft in
Version 3 of Internet Explorer and gained acceptance as part of the HTML 4
specification from W3C. Netscape was slow to adopt this tag, but it is
possible to work around this limitation with ILAYER, which is specific to
Netscape 4. There is a compatibility chart here:
http://developer.netscape.com/evangelism/docs/technotes/xref/html-element/
With the use of IFRAME and ILAYER, it is possible to build something that
resembles a socket connection between the HTML page and the server. Data
can be passed to the server and received back from the server without
navigating away from the client interface that the IFRAME is embedded in.
The protocol is http, and JSP / Servlets or any other script language can be
used on the server side, depending on your implementation. In this model,
all the data is passes into the appropriate Javascript functions, which
creates element objects from the data, and dynamically places them within
the page. The Document Object Model (DOM) allows access to any named
element of the HTML page, including tables, forms, text, and images. This
combination of the DOM and IFRAME technologies allows the web application to
leverage the power of server-side scripting, while maintaining layout and
design control. Other Possibilities: I am not sure if firewalls would affect
socket connections. Any of the solutions that depend on them could be
vulnerable to difficulties connecting. This includes Flash, Applets, and
ActiveX controls. I also have had problems with applets embedded in JSP’s.
Working out a request / response model is important with one team working on
the client and one team working on the server. XML is the best way to send
information to both the html app and the stand-alone app. In the http app
the XML objects would be built in memory and queried using Javascript, and
in the stand-alone app the XML object would be built and queried using java.
The server would send the out the same XML regardless of which client asked
for it. As an added benefit, using XML as the data structure could allow
other clients to be written for cell phones and palm pilots, which could
then format the data according to the device capabilities.
5.3. A.F.'s note
I see Flash as the only good solution to their problem. any other method has
too many flaws to be considered except for maybe JSP/HTML. For communication
I would suggest SOAP/XML versus TCP because of the ease of implementation
and extendibility.
5.4. J.N.'s note
My main concern with applets is their "clunky" nature. They use an older
version of Java, so any bugs will have to have workarounds. Second, they are
not guaranteed to be supported in all browsers. IE will not support Java, so
a separate plugin will have to be downloaded before the applet becomes
useable. Microsoft has made it very clear that they will not support Java.
Using something like Java Web Start is still a long download for anyone
using a modem. Java won't handle HTML very nicely, so it would make sense to
have the browser handle the rendering of HTML. Applets won't work well in
this situation. A Java server app, serving HTML would be a better solution
in this case. TCP connections are a problem with applets if the applet is
connecting to another server (ie mail server). Then signed applets come into
the picture. Since there are different permissions for Netscape and IE, the
signing procedure becomes a headache. To get around signing applets, the use
of servlets to communicate to other servers can be done. But this uses HTTP
connections, which was mentioned as something not to be used. Firewalls are
a problem as well, but this would need servlets again to communicate with
other servers using HTTP. Because of the three cases above (TCP connections,
HTML mail, firewalls), using a Java server app to serve HTML seems to be a
better fit in this case. This would not have a shared codebase with a stand
alone client though.
5.5. H.L.'s note
I would suggest to use a servet to act as a bridge between browser and
server program, that is a solution that use HttpURLConnection to communicate
with a servlet, which staying in the server side, and have full access to
server environment and resource. Because we only use HTTP protocol instead
of directly opening a network connection to server using raw socket
interface, firewall will not become a issue. In order to keep the applet
code as smaller as possible. I don't encourage to use any other plug-in
product because we need to keep Applet code as smaller as possible. How to
share code with standalone application is not that critical issue, it can be
done with good design.
5.6. M.O.'s note
Support for Java and Java Plug-in. Because of anti-trust issues Microsoft
has dropped default support of java in its newest Windows XP operating
system. As the result Internet Explorer 6.0, bundled with Windows XP comes
without Java Virtual Machine. The Microsoft JVM can be downloaded free of
charge from the Microsoft site:
http://www.microsoft.com/java/vm/dl_vm40.htm. Alternatively users can easily
download and install the standard Java Plug-in from Sun, considered by many
one of the best things that happened to browser-based Java:
http://java.sun.com/getjava/download.html and use it either with Internet
Explorer or Netscape Navigator. The installation process is pretty
straightforward. Once the JRE is installed, your applet gets downloaded and
cached, and then opening an HTML page with your applet is instantaneous,
since everything is loaded from the client's disk. Using the common Java
Plug-in from Sun has obvious advantages versus relying on a browser built-in
JVM: all the users are using the same (newer, faster and better) JVM built
with the same code base as JDK (currently 1.3_01, but I believe 1.4 is on
its way) and by the same vendor (Sun Microsystems) regardless of the
operating system and browser used. That results in application features
unification and is the approach used heavily by Acterna for most of its
products. Those who tried using applets in the early days of Java remember
hours wasted fighting with the differences among browsers, applet download
time, performance, and other problems. From my point of view using Java
Plug-in clearly outweighs all additional efforts required to install the
plug-in on the user’s machine, which BTW should be done only once. Moreover,
considering Microsoft’s own JVM stopped at 1.1 and does not catch-up with
newer versions of JDK/JRE, anyone who desires to use serious client-side
Java software, for instance a product with a Swing GUI, which needless to
say has numerous advantages over AWT, installs the Sun JRE plug-in anyway.
Once that is installed, Java can do everything on a Windows XP system it can
do on other systems. Socket Connections through Firewall. The actual
communication from the client application/applet to the server application
require a TCP socket, and given the issue of a client potentially located
behind a firewall, we have to consider some architectural issues here. An
applet is very restrictive in its use of sockets. As we know an unsigned
applet is allowed to connect back to the same host it came from, and it
works most of the time, except when the client applet is running behind a
restrictive firewall. In some cases a fixed port can be nailed down and the
problem can be solved by opening a specific port in the firewall, allowing
socket connections on it, and then use that port in the client and server
code. If the first approach did not work for some reason (because a free
port number is assigned from the heap, the organization has the policy of
keeping the ports blocked or the firewall used only accepts certain well
known protocols like HTTP), you should use the java.net.HttpURLConnection
class to connect to a URL that points to a Java Servlet, serving as an
intermediary between client and server, using HTTP protocol. Then, the
servlet opens a socket to the server and waits for the response from server.
After the servlet gets the response, it sends result back to the client
applet, containing the data you need to get back to the applet. The downside
is that the connection can be slower than TCP, resulting in possible
perceived deteriorated applet performance by the end user. Applet vs. Web
Application Choosing between AWT/Swing and HTML-based GUI requires special
design considerations. Each of the approaches has its pros and cons. The
strongest argument choosing HTML is its wide acceptance on any platform, we
don’t have to worry about client’s hardware, operating system and browser
because when Java Servlets and JSPs are used to deliver HTML contents all
the processing is done on the server (except client side JavaScript for on
screen validations, on screen updates, etc.), and given the simplicity of
HTTP/HTTPS protocols, we are also guaranteed to enjoy the predictability of
programming for various network configurations and firewalls. But there is a
high price to pay for an HTML-based client, considering the lack of user
interaction and the necessity of making network trips to the server for
every response to a user action. Although thin clients offer ways for great
presentation of many noninteractive user interfaces, traditional fat clients
certainly surpass them in intelligence. For example nobody can argue that
email client applications are much more user friendly than Web-based email
portals. To summarize, an HTML front end using servlets and JSPs is a great
way to develop static content. However, this thin client doesn't score very
high when you need quick responses to the users' actions and sophisticated
logic that manipulates data quickly. The compromise to use Java applets in
your web application sparingly and do so only when absolutely beneficial in
combination with on screen HTML and DHTML yields the best all round result.
However, if the requirement is to develop an application capable to run as a
stand alone and in the browser leads to having a substantially different
code base for the stand alone and web applications, with different look and
feel, which might not be acceptable. Java applets and DHTML are not the only
way to spice up the client content. There are many 3rd party technology
plugins available. Some that come to mind are Shockwave Flash, Real Media,
and Cosmo Player although there are many more. However using those can not
be considered as the standard option and should be used only if there is a
compelling reason to do so. Each front-end technology has its benefits and
disadvantages when it comes to the interface to your Java applications. None
of them is superior to others in all aspects. For each specific application,
we must perform an evaluation of these technologies with analysis of
requirements and user expectations. Here are the basic rules of thumb: Use
HTML/JSP: - For relatively static content enriched by graphics and
professional art - If your interface needs to work for all user types
running different software - If users access your application from slow
networks - If you want to quickly build an unsophisticated application Use
Swing applet: - For highly interactive GUIs with built-in, interface-related
logic - To reduce network traffic and provide immediate response when
possible - If users have high expectations for the quality and functionality
of the interface - If UI functionality is more important than aesthetics
Another emerging way of deploying Java applications is by using Sun's Java
Web S
