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, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], � � 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 [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.rebol.com/feedback.html [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED], 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED], 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 and link it first and then distribute the single executable, but then we probably need to buy the source? Waht other components we may need? What is IOS for? � what unit and GUI test tools are available? Debuggers? � for the serious project our 2-week familiarity may not be enough, but there are no Rebol experts around. � No direct multi-threading; � No dedicated debugging means; Other. � If use it anywhere, the first choice is probably to ask sys-admin guys to install it for inter-company communication, get used to it and then think of further usages. � Basically we can freely re-distribute their view.exe component along with our myMailloop.r script file � If we require more features along the way (which is hard to foresee with our current level of expertise), they start charging considerably � Anyways it just looks like another form of developing native apps that we already can do in Perl and C++. I do not see how it can become a web app running in a browser. Acceptance Rejected as not multi-threaded, quite singular and having complex pricing policy. 7.10. Maui Description Bitmovers� product generating HTML in run time for Swing original. Sources � Bitmovers Systems Inc. 402-329 Railway Street, Vancouver, BC V6A 1A4, CANADA, 1-877-733-4533 is not in service, 604-733-4533, both mail boxes are full, [EMAIL PROTECTED], [EMAIL PROTECTED] do not respond. Seems, they went out of business. � Candidate D.W. Client downloads Same as for JSP. Testing. � Unit testing. Junit for testing Swing source and HttpUnit for testing generating web application. � Automated GUI testing. Just like for JSP. Multi-threading Not on client side just like for any HTML page. Once any request is generated, page freezes until response comes. Yes for Swing original and unknown for their servlet app. Pros � cheaper than WebCream � local � saves on cost of web application development � we do not need synchronization of stand-alone and web app for every update. Cons � not popular enough. We may run into unexpected issues. � Slow. � Unlike WebCream, it needs code modification. � Out of business � We lose control of web app with such an approach � In stand-alone app we should allow more than in web, for instance, saving into local files. Acceptance Rejected as the one having HTML client, vendor is out of business and many other things. 7.11. WebCream Description CreamTech�s product generating HTML in run time for Swing original. Sources � http://www.creamtech.com/webcream CreamTec, LLC PO Box 230833 Centreville, VA 20120-0833, [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] � candidate M.O. � candidate D.W. Client downloads Same as for JSP. Testing. � Unit testing. Junit for testing Swing source and HttpUnit for testing generating web application. � Automated GUI testing. Just like for JSP. Multi-threading Not on client side just like for any HTML page. Once any request is generated, page freezes until response comes. Yes for Swing original and unknown for their servlet app. Pros � saves on cost of web application development � we do not need synchronization of stand-alone and web app for every update. Cons � just like Maui it is not popular enough (but still more popular than the latter). We may run into unexpected issues. � more expensive than Maui � Slow. � We lose control of web app with such an approach � In stand-alone app we should allow more than in web, for instance, saving into local files. � Unlike Maui, it does not need code modification. Other Acceptance Rejected as the one having HTML client, quite costly and many other things. 7.12. SOAP Description W3C�s specification on messaging format. We can use it to talk between different layers of our system. Sources [EMAIL PROTECTED] mail list, www.w3c.org, microsoft, � Testing. � Unit testing. HttpUnit for client testing in any case, Junit for Java server side and perhaps CppUnit for C++ side testing. � Automated GUI testing. For Dean to evaluate. This must be not a GUI event tool, but perhaps some data parsing tool. Client downloads In case of using it on client�s machine (all except HTML and Flash based clients) we need at least 180k of additional library. Data traffic also has size overhead because data is wrapped into XML tags. Pros � supported by communities � fashionable � provider independent Cons � slow � requires libraries � there are slight vendor�s incompatibilities. Other A.F. proposed this communication protocol with HTTP carrier, and Rick approved. Then applet needs for instance Apache's soap.jar or 180k. Alternative communicational library will take some size anyways. W.V. and D.K. think SOAP is an overkill for the project. W.V. proposes RMI and JNI instead. SOAP is not so universal a thing. There are some issues of providers and clients compatibility. And having so diverse environment, we will definitely need to use different packages. Perhaps Apache SOAP in Java and MS SOAP in some native Windows code. Perhaps, we need to use org.apache.soap.providers.com.RPCProvider class if our SOAP service is Apache Java (C:\programs\soap-2_2\samples\com\readme.htm). Or if it is MS implementation, we need to adjust java client for it. People say that SOAP is slow, has lots of data overhead and therefore is rarely used on desktop or client web apps. Rather it can be used between two server machines as peers. Acceptance Accepted as more fashionable than CORBA and perhaps other reasons Rick can provide. 7.13. RMI Description Sun�s narrowing of CORBA. Object exchange protocol over TCP. Sources Sun Client downloads It adds nothing to regular Java application download size. Testing. � Unit testing. General Junit. � Automated GUI testing. Perhaps, nothing is available. Unit tests should suffice. Pros � easier than CORBA or SOAP Cons � just Java to Java, where as we have C++ component. Other V.W. suggests using it to talk between stand-alone Java client and some intermediate Java Java app server. Acceptance Rejected as Java-to-Java thing whereas we may have just one Java layer. 7.14. CORBA Description OMG�s object exchange protocol over IIOP. Sources OMG, � Client downloads Perhaps it adds a little to JRE 1 and nothing to JRE 2. Perhaps a little more libraries in case of native stand-alone application. Testing. � Unit testing. Junit on Java side, CppUnit on C++ side and perhaps some CORBA specific resources need to be found out if need comes. � Automated GUI testing. For Dean to evaluate. Pros � more universal than RMI, just like SOAP Cons � too heavy for applets � difficult at many aspects Other Acceptance Rejected for the Reasons Rick can explain. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
