Thanks for sharing this. Having started in a new environment I feel your pain. Sadly I find myself doing more and more in P&P (Perl & Python) as they *do* interface with the rest of the world and have a vibrant community. Let alone the license policy...
It's a tough conclusion, and if things change I may return to be a REBOL again. For now.... goodbye --Maarten On Thursday 02 May 2002 18:56, you wrote: > 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.
