using Rebol for mail client app
[1/14] from: boris:garbuzov:marketingtips at: 18-Apr-2002 17:50
We are kindly asking experts' opinions on this list about reasonability of
using Rebol technology for mail client app.
The whole list of possibilities includes HTML, applet, JavaWebStart, Flash,
IFRAME, Rebol IOS, WebCream, Maui. Can briefly comment on basic capabilities
of your IOS? After reading short description on your web site I am under
impression that it is some inter-organizational environment like Lotus Notes
or FiloSafe to share data and services. What we are looking for is some base
technology (like applets were intended to be) to run our thin client
application for paid customers across the web. Sincerely yours, Boris.
[2/14] from: ammon:rcslv at: 18-Apr-2002 20:36
Hi and Welcome to REBOL!
REBOL is perfectly fitted for your application in every way!! REBOL does
amazing things for networking & is definitely designed to run, as you
mentioned, as *thin client*.
There have been a few starts at actually building a mail client, but the
developers have gotten to busy to be able to continue to contribute to the
project. There was a current attempt (within the last 6 months), the project
was practically killed by, or around the time of Sept. 11. But the mail list
still remains, [RebMail--yahoo--com], it is a Yahoo! Group. You are welcome to
join the group, & contribute any time that you may have available to the Open
Source project. I intend to get back to the project when/if I can.
HTH
Ammon
CIO
Tricom Communications
A short time ago, Boris Garbuzov, sent an email stating:
[3/14] from: chalz:earthlink at: 19-Apr-2002 1:10
This is my personal opinion, from what I've read, without trying IOS. But
you might want to use REBOL/Core (for a text interface) or REBOL/View (for a
gui) for your mail client. I don't really think you need IOS for all of that.
My impression of IOS is that it's a whole suite of programs and systems and
such. REBOL/Core and REBOL/View are free to work with and such (though
REBOL/View/Pro costs a few bucks). There's also REBOL/Command for a couple
hundred bucks, for the pros out there.
If all you're after is a thin mail client, I think /Core or /View would be
plenty. You could even use an HTML interface to /Core code, so you don't have
to learn any new GUI coding (not that /View is all that difficult).
[4/14] from: anton:lexicon at: 19-Apr-2002 16:46
Boris,
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?
Anton.
[5/14] from: philb:upnaway at: 19-Apr-2002 23:48
Hi Boris,
Well you might want to take a peek at my email client.
(desktop->sites->philb->email client)
I have just uploaded the latest version 2.0.0 to my Rebsite
This is a 46k script that I have been using as my mail Mail reader for 6 months.
Cheers Phil
=== Original Message ===
We are kindly asking experts' opinions on this list about reasonability of
using Rebol technology for mail client app.
The whole list of possibilities includes HTML, applet, JavaWebStart, Flash,
IFRAME, Rebol IOS, WebCream, Maui. Can briefly comment on basic capabilities
of your IOS? After reading short description on your web site I am under
impression that it is some inter-organizational environment like Lotus Notes
or FiloSafe to share data and services. What we are looking for is some base
technology (like applets were intended to be) to run our thin client
application for paid customers across the web. Sincerely yours, Boris.
[6/14] 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
[7/14] from: ammon:rcslv at: 19-Apr-2002 11:54
Hi,
I just looked at your client, it seems to be fairly complete, but still
needs a few things & has a few bugs. I was unable to test it as the account
selector down by the "get mail" button wouldn't update itself when I added
new accounts.
HTH
Ammon
A short time ago, [philb--upnaway--com], sent an email stating:
[8/14] from: philb:upnaway at: 20-Apr-2002 9:22
Hi Anton,
Yes still some bugs :-( .... and a few important things missing ....
(Forwarding, CC ing, Sending to multiple recipients, Up to Date documentation etc
.... they just havent been important enough for me to fix .... yet).
Hopefully it will improve over the next few months.
But I just wanted to show Boris that it is possible to write an email client.
Cheers Phil
=== Original Message ===
Hi,
I just looked at your client, it seems to be fairly complete, but still
needs a few things & has a few bugs. I was unable to test it as the account
selector down by the "get mail" button wouldn't update itself when I added
new accounts.
HTH
Ammon
A short time ago, [philb--upnaway--com], sent an email stating:
[9/14] from: anton:lexicon at: 20-Apr-2002 21:48
Boris,
It is still a little unclear what your application will do.
I guess it is just like any email client, able to send and
receive mail, sort them into groups, by date, importance etc?
Plus the ability to autoreply to messages that match certain
criteria specified in filters.
Plus the ability to scan messages for addresses.
Ok, I see the toughest issues to solve will be
- installation of the rebol client
- building certain gui elements such as lists and tables
that match your needs. (These are being worked on right now,
however. These existing ones might be sufficient for your needs.)
- Depending on what kind of communication needs to occur between
the server and client, you may also have some issues here, but
basic messaging is really simple with rebol.
More on Installation:
There are some browser plugins that help install it from IE and Netscape.
http://www.reboltech.com/plugins.html
Since versions of IE later than 5.5 don't support plugins, there is
no plugin for these, and it was discovered that a fair bit of work in
ASP (?) was needed to get that to happen. But it is solvable.
Rebol/View can be installed for free and is a small download
of around 500k. That's all. It also is very easy to install,
so it would be easy to write a doc explaining to the user how
to install it. You should try it to see how.
http://rebol.com/view-downloads.html (click Proceed to get to...)
http://rebol.com/view-platforms.html (<--- direct link)
Installation is still a bit of an issue with internet cafes etc.
But, I think, no matter what language/plugin you choose,
you will still have difficulties installing on such machines
without permission. So this is where the server side comes
in, with all that browser stuff, right?
This is to give the user the option of still checking the
email even if they can't or are not allowed to install any
applications/plugins, right?
I think it is possible, with some clearly written documentation,
to guide the user through all these installation issues quite
quickly, so they don't lose patience.
Security is another issue. If you want to securely
encrypt your data you will need professional (non-free)
versions of rebol. (I suppose you could implement your own
encryption scheme in rebol.)
Sifting through the emails will be really simple with rebol.
There are plenty of examples of how to parse through text and html
to extract data. (And plenty people to help you on this list with
parse questions.)
I hope this helps you make up your mind.
Feel free to ask more questions.
Anton.
[10/14] from: robert:muench:robertmuench at: 20-Apr-2002 15:54
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 5>>
> This is a 46k script that I have been using as my mail Mail reader
> for 6 months.
Hi Phil, somehow I missed this Reblet and would like to try it. The uploaded
version seems to be missing some files: prefs, locals etc. could you please
check this? I wan't able to get the client to work. Robert
PS: With a Rebol mail client my outlook days might have been counted :-))
[11/14] from: philb:upnaway at: 21-Apr-2002 0:07
Hi Robert,
I think the latest version is up on my Rebsite.
It should be Version 2.0.0 with size 48055 bytes.
(if it isnt then its probably a cache problem)
Also if you ever tried an earlier version I have changed the format of the
preferences file and the way in wwhich locale's work. If you have old versions
of these then that would cause a problem.
Try clearing your cache for www.upnaway.com/~philb/.
I just did that and View correctly downloaded version 2.0.0 created the default
folders & default preferences file for me.
Let me know if you still cant get it to work. I can email you the program direct
if you wish.
The code is compressed to keep the download time (and to hide some of my ugly \
code!).
As has been pointed out there are still bugs to iron out .... but it seems pretty
stable here. I use it for all my email requirements .... it has processed over
19000 emails ... mostly from the Rebol mailing list.
Cheers Phil
p.s. I used your make-doc-pro.r to create the helptext .... much easier than
coding it by hand :-)
(Good stuff)
=== Original Message ===
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 5>>
> This is a 46k script that I have been using as my mail Mail reader
> for 6 months.
Hi Phil, somehow I missed this Reblet and would like to try it. The uploaded
version seems to be missing some files: prefs, locals etc. could you please
check this? I wan't able to get the client to work. Robert
PS: With a Rebol mail client my outlook days might have been counted :-))
[12/14] from: kenlo:myrealbox at: 22-Apr-2002 14:17
Thank you Phil, the mail client is good. I spotted a few issues.
1. Fetchmail should use user name instead of account name.
2. Sendmail dosen't authenticate. This can be done by opening and closing the pop server
before and after the send.
3. Multiple account seems not working.
[13/14] from: philb:upnaway at: 22-Apr-2002 16:33
Hi,
On 1 & 3 ...
Multiple accounts should be working .... I have 2 seperate email acccounts here
and I can fetch email for both accounts.
On pressing the Fetch Mail button I just wanted to display the Account Name
in the Pop-up window .... this shouldnt be input capable.
The popup is only there to fetch the password.
(The user name used is derived from the account name on the rotary button.)
I could display the user name if required.
(This I have been meaning to fix for a while but havent got around to it ... will
look at it tonight ... but its easily fixed).
The POP scheme the program uses is taken from
system/schemes/pop/algorithm
My ISP doesnnt support APOP so I cant test it :-(
As I am the only person to be uding this Mail program the testing hasnt been
really extensive.
If you are still having problems .... then let me know.
Cheers Phil
=== Original Message ===
Thank you Phil, the mail client is good. I spotted a few issues.
1. Fetchmail should use user name instead of account name.
2. Sendmail dosen't authenticate. This can be done by opening and closing the pop server
before and after the send.
3. Multiple account seems not working.
[14/14] from: philb:upnaway at: 23-Apr-2002 16:03
Hi,
You may like to try 2.0.3 just uploaded ....
Cheers Phil
=== Original Message ===
Hi,
On 1 & 3 ...
Multiple accounts should be working .... I have 2 seperate email acccounts here
and I can fetch email for both accounts.
On pressing the Fetch Mail button I just wanted to display the Account Name
in the Pop-up window .... this shouldnt be input capable.
The popup is only there to fetch the password.
(The user name used is derived from the account name on the rotary button.)
I could display the user name if required.
(This I have been meaning to fix for a while but havent got around to it ... will
look at it tonight ... but its easily fixed).
The POP scheme the program uses is taken from
system/schemes/pop/algorithm
My ISP doesnnt support APOP so I cant test it :-(
As I am the only person to be uding this Mail program the testing hasnt been
really extensive.
If you are still having problems .... then let me know.
Cheers Phil
=== Original Message ===
Thank you Phil, the mail client is good. I spotted a few issues.
1. Fetchmail should use user name instead of account name.
2. Sendmail dosen't authenticate. This can be done by opening and closing the pop server
before and after the send.
3. Multiple account seems not working.
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted