using Rebol for mail client app

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.

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:

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).

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.

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.

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

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:

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:

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.

> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of > This is a 46k script that I have been using as my mail Mail reader > for 6 months.

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 > This is a 46k script that I have been using as my mail Mail reader > for 6 months.

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.

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.

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.