A study of researchers shows that many decisions are taken long BEFORE technical arguments are presented and that those arguments are above all used to confirm decisions already taken than to objectively evaluate the best solutions. In some cases Java is better, on other cases it is not. So I don't think that people has to generalize and I don't understand why there is a long list about Java as this is a mailing list about rebol.
----- Original Message ----- From: "Maarten Koopmans" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 02, 2002 8:43 PM Subject: [REBOL] Re: evaluation result (or... goodbye) > 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. > -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
