evaluation result

Sorry for a long message, and thanks to all those experts assisting us of evaluation of Rebol technology for mail frow namagement client project. I feel obliged to share the results before signing off the list. Shortly, Rebol was rejected for not allowing direct multi-threading, for its singularity on the market and for very trapping licensing policy. The latter particularly means that if we want to ship our app as a single executable, we need to pay royalties. Java 2 stand-alone + JavaWebStart was chosen. Below is detailed report. Boris. ------------------------------- 7. Summary on Technology Choices 7.0. JSP Description Sun;s technology for web applications hand writing. Currently is the most popular base for them. Usually it is mixture of HMTL or XML with java code. Sources Sun’s forums and Apache’s lists… Client downloads No additional software needs to be downloaded. It is just a regular HTML from client’s point of view. But as for any HTML solution the whole page with data and wrapping tags needs to be re-downloaded each time we want to change a piece of data. Testing. · Unit testing. Lots of open source community frameworks, for instance HttpUnit for client, Apache Cactus for server and Junit for general and stand-alone testing. · Automated GUI testing. For Dean to evaluate. Perhaps, some tools on regular browser HTML testing. We may not need automated tools in this case because unit test means cover it quite well. Pros · Popular, many experts in it around. Supporting community is also large. · There are many free engines. · client is just HTML, no download headache · most Java candidates voted for it.. Cons · if it serves HTML, it is the most limited in layout and action amongst other choices. · client is not smart enough Other … Acceptance Rejected as a means of HTML or Flash delivery because they are not multi-threaded. We may still consider some secondary intermediate layer with its usage. Though we can serve our Java 2 application just from a static page. 7.1. Java 1 applet Description Original way to serve java agents to client. Runs is a browser. We can use it for both web and stand-alone client. Sources Sun’s forums, JUG mail lists Client downloads Jre 1.1.8 download size is 2.7 megabytes, in most of the browsers it is installed. Java plug-in size? Windows and Solaris versions are available on http://java.sun.com/products/jdk/1.1/jre/index.html. Seems, plug-in is available just for Windows and Solaris? Browser cashes the applet classes during the session. Otherwise it re-downloads the code each new session. Whereas JRE stays forever after the single download. Testing. · Unit testing. General Junit framework, perhaps, there is some applet-specific. There is Java 1 version for everything. · Automated GUI testing. For Dean to evaluate. Multi-threading Available as in any Java code. Pros · Majority of browsers should support it without downloads · mature and established technology · can run sophisticated code · multi platform Cons · browsers incompatibilities in reality · security limitations · Java 1 becomes obsolete · slow Other · Mixed HTML-applet solution. Both Adrian and Jon Stoski mentioned it to be not so heavy as a whole single applet. But anyways we lose the main goal of having common code base. Acceptance Rejected because Java 1 is obsolete and applet technology goes out of fashion as inconsistent and poorly supported by browser vendors. 7.2. Java 2 applet Description Next to original way to serve java agents to client. Runs is a browser usually through plug-in. We can use it for both web and stand-alone client. Sources Sun’s forums, JUG mail lists Testing. · Unit testing. General Junit framework, perhaps, there is some applet-specific. · Automated GUI testing. For Dean to evaluate. Multi-threading Available as in any Java code. Client downloads Jre 1.4.1 download size is 9.2 megabytes. Plug-in technology is specially intended for Java 2 applet. Seems, plug-in is available just for Windows and Solaris? Browser cashes the applet classes during the session. Otherwise it re-downloads the code each new session. Whereas JRE stays forever after the single download. Pros · Majority of browsers should support it without downloads · mature and established technology · runs the most contemporary Java · multi platform · we can have trees and other cool Swing stuff Cons · browsers incompatibilities in reality · security limitations · 8 megabytes of JRE 2 to download (condenced) · sow Other · Since dropped Java support in XP, there is little download difference with Java 1 applet. Acceptance Rejected because applet technology goes out of fashion as inconsistent and poorly supported by browser vendors. 7.3. C++ stand-alone Description Just like existing Mailloop5 or future Mailloop6, but thinner. We can use it for stand-alone version only. Sources Rick, Paul, … Client downloads Just a small application needs to be downloaded and installed once. No additional software. But as any stand-alone thing it can not be run from the browser without installation. But on the other hand as for any stand-alone application, it must be downloaded and installed just once. Testing. · Unit testing. CppUnit and other for general C++ and specifically for Microsoft studio. Rick also says, it is possible to call COM objects from Java using J++ libraries. · Automated GUI testing. For Dean to evaluate. Perhaps in this case we need automated tools the most. And this is the most common use for them. Multi-threading Available as in any Java code. Pros · GUI is reusable for Mailloop6 · Quick · No security limitations · Easier to talk to C++ Microsoft services. How did it talk before in Mailloop5.0? · Existing people know how to do it. Cons · Single platform Other Acceptance Rejected because it is single platform based and has poor ability to run from the browser. 7.4. Java 1 stand-alone Description Application over JRE 1. Sources Sun’s forums, JUG mail lists Client downloads We can ship with JRE 1.1.8 that is 2.7 megabytes on top of small application size. By cost of slight enlargement we can whip the executable for each platform wrapped into install shield. Or not to care about platforms we can ship the zip and suggest the customer to pre-install JRE. As any stand-alone application, it must be downloaded and installed just once. Testing. · Unit testing. General Junit framework. There is Java 1 version. · Automated GUI testing. For Dean to evaluate. Multi-threading Available as in any Java code. Pros · multi platform · free · has many open source knowledge communities around Cons · requires JRE 1 on client’s machine or should be shipped with it, possibly wrapped into InstallAnywhere executable. · Slight security limitations · Sow · Java 1 gets obsolete Other Acceptance Rejected because Java 1 is obsolete. 7.5. Java 2 stand-alone Description Application over JRE 2. Sources Sun’s forums, JUG mail lists Client downloads We can ship with JRE 1.4.0 that is 9.2 megabytes on top of small application size. By cost of slight enlargement we can whip the executable for each platform wrapped into install shield. Or not to care about platforms we can ship the zip and suggest the customer to pre-install JRE. As any stand-alone application, it must be downloaded and installed just once. Testing. · Unit testing. General Junit framework. · Automated GUI testing. For Dean to evaluate. Multi-threading Available as in any Java code. Pros · multi platform · free · has many open source knowledge communities around Cons · requires JRE 1 on client’s machine or should be shipped with it, possibly wrapped into InstallAnywhere executable. · Slight security limitations · Sow Acceptance Accepted as multi-threaded and partly compatible with browsers. 7.6. Java Web Start Description Free Sun’s implementation of Java Network Launching protocol intended to help rusty Applet technology to run Java 2 application from the browser on client’s machine. Sources Sun’s forums, JUG mail lists Client downloads The download and installation process stays in between customary concepts of stand-alone and web application. There is no plug in for it. Usually there is a link for the customer to download 9.2 megabytes of JRE 2, plus 8 megabytes of JavaWebStart on top of it. This is a single download and installation of base and our software. No other downloads and installations are ever expected unless we encourage it from the server if we need to update the application’s version. Testing. · Unit testing. General Junit framework. Perhaps there are some specific issues and special frameworks and design solutions for them. · Automated GUI testing. For Dean to evaluate. Multi-threading Available as in any Java code. Pros · multi platform · free · has many open source knowledge communities around · 8 megabytes of download over 9 megabytes of JRE 2. Cons · requires JRE 1 on client’s machine or should be shipped with it, possibly wrapped into InstallAnywhere executable. · Slight security limitations · sow Other Kind of a plug-in that helps client run java stand-alone apps from browsers. There is no research on browsers’ support and how smart it is. Also, JN thinks it is too much of download headache for a customer. V.S.’s point is that by using JavaWebStart we can develop just one client version and use it in two ways. More and more people suggest it. V.W. thinks, it helps to automate version upgrade routine. Now if to compare Java2 applet and JavaWebStart app, apart from reliability issues - what is the principal difference? I think, first of all in download cycle. Java 2 applet requires to download Java 2 VM once and applet every new browser session. Java Web Start requires to download VM once, target application also once (unless newer version detected) and some Java Web Start thing in addition. So they both download Java2, though applet may be cashed but never installed into the system, whereas Java Web Start requires more to download first time, but less all subsequent times. Some security issues may arise. For instance, if the user tries to access his system from the Kinko's, Internet Cafe or public library, those machines will surely allow applets but may disallow target app installation from Java Web Start, and disallow to install very Java Web Start. Is that right? These are just my premature guesses. This is what response I got from Sun’s forum on plug-in for JWS: I don't believe that JWS can boostrap itself onto a client. In my test so far, I have a link in my web page to the appropriate sun URL from which the user can download the JRE and/or the JWS. They must first do that before downloading my application using JWS. You can provide a link to http://java.sun.com/products/javawebstart/ for people to download. It will auto-detect your operating system. Acceptance Accepted as more fashionable than applet way of running from the browser. Also, we need to write just one application, not 2, no headache with version synchronization. 7.7. Flash Description Macromedia;s technology to show vector graphics in a browser, alternative to HTML. Data source is binary. The server side Salsa script and J2EE connection through paid Macromedia’s Gateway is possible. Sources · Macromedia, Inc. 600 Townsend Street San Francisco, CA 94103 Tel: (415) 252-2000, [info--macromedia--com], [support--macromedia--com], [home--macromedia--com], [all--macromedia--com], [sales--macromedia--com], [webads--macromedia--com], … · Open sources: http://www.anotherbigidea.com/javaswf/index.html, http://www.orgdot.com/javaopensource/, · From A.F.: www.flashgap.com and www.jzox.com. Client downloads 0.5 megabytes player and in most of the cases nothing needs to be downloaded once. Then media size is bigger then HTML, but still small if no animation is used. Data reload may be organized economically unlike in HTML. Perhaps, bigger player must be downloaded for Flush MX that has built-in standard controls library. Testing. · Unit testing. specific Flash solutions need to found out. Perhaps, it can be debugged. If it is within HTML page, probably Junit can still be applied, if it is served from JSP server, Junit and Cactus will be used. · Automated GUI testing. For Dean to evaluate. Multi-threading No. Pros · - it is much richer than HTML. · - supported by 98% of market client browsers. · - requires very little to download in plug-in fashion if any at all. · We may need to buy merely nothing at all · - tends to be a base for new browsers, is in fashion. There are many Java open source packages for SWF rendering and automatic content update. · Generally it is deep and growing technology, so we may commit to it not fearing licensing traps. · - looks less fragile then Java Applets. · - has possibility smart action and communicational scripting. · Allows dynamic content generation through open source Java APIs. Cons · - increasing development cost. We do not have many people around experienced in dynamic Flash applications. To connect it properly to back end. And sure it is harder to incorporate it into standard server technoloties like JSP comparing to HTML. · - some parts of this technology are not free. Development tools, gateway if we need it... · - it may be disallowed by customer due to reputation of heavy overuse. Customer may be afraid of nasty media. Other · I still do not know about multithreading here. I will know by tomorrow. Acceptance Rejected as not multi-threaded. 7.9. Rebol Description Core component is a base for Perl-like scripting language. View component adds GUI, many other components add options. IOS seems to be inter-organizational environment like Lotus Notes or Filosafe. Sources [rebol-list--rebol--com], [info--rebol--com] http://www.rebol.com/feedback.html [grossdog--dartmouth--edu] Client downloads 0.5 megabytes of view.exe must be pre-installed and then really small script text file application on top of it. Perhaps, we can compile and link it together with Rebol base and then ship. That size should not be large too. Perhaps we need to buy more from Rebol in this case. Testing. · Unit testing. As [greggirwin--mindspring--com] says, since REBOL doesn't support step tracing at this time, the console and embedded print statements are the most common debugging tools I think, at least they are for me. There is also a unit testing script (based on JUnit?), called rebol-unit. According to [ryanc--iesco--biz], testing is done at the console level. Generally REBOL is easy to test and debug once you understand how evaluation occurs. When an undefused error occurs, the program breaks into console mode, much like BASIC. At this moment you can peer into your program, test values and functions, somewhat useful. Usually though, you add probes into the suspect area of your program to make sure it is doing what you expect. Almost all bugs I encounter are fixed within a minute or two, and often just seconds. The tools are not nearly on the level of Visual BASIC, though somehow debugging goes pretty easy in REBOL. · Automated GUI testing. For Dean to evaluate. Perhaps we can consider it just like regular native GUI application, especially if we compile it on server. As to specifics, Boris may ask on mailing list. Multi-threading · As [greggirwin--mindspring--com] says, REBOL doesn't support native multithreading. Maarten's latest release of Rugby has cooperative multithreading in it as an example of how you might approach it. · According to [ryanc--iesco--biz], no forking in native rebol. Here is a simple 2 line a piece master and slave demo, made in about twominutes. This is one way to communicate between processes. You may also should be able to tie processes together with better performance by using C functions. I cant give you an example of that. Does anybody know if you could fork using a C function from REBOL? Pros · EK recommends it as another “run anywhere” thing · It may help us for managing remote space for clients saving their list files there. Cons · seems, it is not intended to be used for this purpose. · Not free. · it is not a popular solution, so we may run into unexpected technical and business license traps. For instance · what serious projects had used Rebol? · what is the way of delivery to client - myapp.r and view.exe files? Can we re-desctribute the components? What should we buy then? Or we can compile a

Thanks for the update Boris. Hopefully RT is listening. Good luck with your project. --Gregg