how to start?
[1/7] from: boris:garbuzov:marketingtips at: 25-Apr-2002 15:05
I need to evaluate this technology for one project. What are my first steps to install something free and play with it?
[2/7] from: carl:cybercraft at: 26-Apr-2002 12:43
On 26-Apr-02, Boris Garbuzov wrote:
> I need to evaluate this technology for one project. What are my > first steps to install something free and play with it?
The free (for non-commercial-use) versions can be downloaded from these two pages... http://www.rebol.com/platforms.html http://www.rebol.com/view-platforms.html The first link's for REBOL/Core and the second for REBOL/View, View being REBOL with a GUI and graphics and a desktop to "rebsites" on the Net. Installation's reasonably simple. If it's IOS you are interested in, there's a form to fill in to make a request to evaluate it. Click on the TryIt link in the menu on the left on the rebol.com site. -- Carl Read
[3/7] from: cybarite:sympatico:ca at: 25-Apr-2002 13:26
Boris, You might get a step up on your evaluation if you tell the list what you need to accomplish. There are lots of ideas and pre-written code that could get you going. And the list people are amazingly helpful ...
[4/7] from: boris:garbuzov:marketingtips at: 26-Apr-2002 11:12
Thanks to all honorable list members for your good will to help in our evaluation. I am posting the brief project description below. We are evaluating applets, Flash, JSP, JavaWebStart and other technologies for client implementation. And we wonder if your Rebol IOS can fit into any part of the architecture. Currently I am under impression that it is some inter-organizational communication environment like Lotus Notes or Filosafe. If so, I know not how to use it to distribute the product to paid customers on the web. But anyways, to feel my effort complete, I want to install and try your soft even if it is of no use in the project. ---------------------------- Under review is mail flow management system that is an upgrade of existing Mailloop5.0 Windows stand-alone application. (autoreplies, address list accumulation and stuff, recruiters for instance can use it a lot) 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. ---------------------------- Boris, You might get a step up on your evaluation if you tell the list what you need to accomplish. There are lots of ideas and pre-written code that could get you going. And the list people are amazingly helpful ...
[5/7] from: ryanc:iesco-dms at: 26-Apr-2002 15:29
>From a technological standpoint there is little doubt that a REBOL client would
be an excellent choice. The real question is will the REBOL licensing scheme work for this project. --Ryan Boris Garbuzov wrote:
[6/7] from: mla:itinko at: 26-Apr-2002 23:44
Boris.. Having worked extensively with Java I can say that you do NOT want to use Java Applets for browser client. It's just too difficult managing the Java plug in versions across different browsers and clients. After developing a legacy app as an Applet we converted it to server side java and html client. And at a minimum use Java 1.3. There are just enough bugs in the earlier stuff to give you grey hair and sleepless nights. I do like the idea of Flash client if you are using Flash MX because of the built in GIU controls which look like the platform style controls. And you can do some really elegant stuff with it. But clients will have to have Flash Player 6 plugin. Being new to Rebol I can't see using it for GUI interface but love it for scripting and parsing. Not sure how you would implement asynchronous threads for interface event handlers which is really easy in Java. My 2 cents. Michael
[7/7] from: boris::garbuzov::marketingtips::com at: 26-Apr-2002 18:23
I am very glad that you find the technological place for Rebol in our project. If so, I do not think price or license will be an issue. Can you then kindly describe that usage? Below I quote our evaluation list where Rebol is one of the 16 choices. Sorry if I overload your list with this volume. ============================================================================ ====== 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. Pros . client is just HTML, no download headache . client is not smart enough . most Java candidates voted for it.. Cons . if it serves HTML, it is the most limited in layout and action amongst other choices. 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 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 Notes . 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. 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 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 . 22 megabytes of JRE 2 to download (unpacked) . sow . Notes . Since dropped Java support in XP, there is little download difference with Java 1 applet. 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, . 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? Cons . Single platform . 22 megabytes of JRE 2 to download (unpacked) Note 7.4. Java 1 stand-alone Description Application over JRE 1. Sources Sun's forums, JUG mail lists 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 7.5. Java 2 stand-alone Description Application over JRE 2. Sources Sun's forums, JUG mail lists 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 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 Pros . multi platform . free . has many open source knowledge communities around . 8 megabytes of download over 22 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 Note 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. 7.7. Flash Description Macromedia;s technology to show vector graphics in a browser, alternative to HTML. Data source is binary. 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], . 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. . - tends to be a base for new browsers, is in fashion. . - looks less fragile then Java Applets. . - has possibility for smart action and communicational scripting. 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 is new and owned by Macromedia, there is not so much freedom around it, not so many knowledge sharing communities (though still many) and open source projects as around Java. . - it may be disallowed by customer due to reputation of heavy overuse. Customer may be afraid of nasty media. Note There will be less Java in this case. A.F. suggests it as an alternative to poor HTML layout if the latter is not acceptable. What kind of web app should serve it? J2EE would be good. Flash technology extends and enriches client interface experience. It is owned by Mactomedia. What is free and what is not? What is a relation to open source communities? Player is free, but not an open source. I do not think, it is open to reproduce or redistribute, perhaps, just like JDK. There is a connection to J2EE back end through Flash Gateway that is about 260k. The server connection script Salsa is available. It also connects to Cold Fusion back end that we do not need. Dot Net connections were mentioned. Gateway's implementation is not free, but seems, allowed to be reproduced. Protocol is open free. The Gateway is included in Jrun (just expensive enterprise version?). Server connected Flash app acts like Java applet. It does not need to reload pages and to get valuable data inside the tags overhead wrapper only. There are no open source communities around it yet and no implementations alternative to Mactomedia. To have the full Flush game we need J2EE back and, so another layer between C++ services and final client. In addition, we need to purchase Gateway or the whole Jrun. Is it worth it? 7.9. Rebol Description 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] 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 Notel. 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. 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, [info--bitmovers--com], [maui-support--bitmovers--com] do not respond. Seems, they went out of business. . Candidate D.W. 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 . 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. 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, [Info--creamtec--com][sales--creamtec--com][support--creamtec--com], [alex--kalinovsky--creamtec--com], [creamtech--creamtech--com] . candidate M.O. . candidate D.W. Pros . saves on cost of web application development . we do not need synchronization of stand-alone and web app for every update. Cons . 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. 1. HTML run time generated from WebCream server a. Resource 7.12. SOAP Description W3C's specification on messaging format. We can use it to talk between different layers of our system. Sources [soap-user--xml--apache--org] mail list, www.w3c.org, microsoft, . Pros . supported by communities . fashionable . provider independent Cons . slow . requires libraries . there are slight vendor's incompatibilities. Note 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. 7.13. RMI Description Sun's narrowing of CORBA. Object exchange protocol over TCP. Sources sun Pros . easier than CORBA or SOAP Cons . just Java to Java, where as we have C++ component. Note V.W. suggests using it to talk between stand-alone Java client and some intermediate Java Java app server. 7.14. CORBA Description OMG's object exchange protocol over IIOP. Sources OMG, . Pros . more universal than RMI, just like SOAP Cons . too heavy for applets . difficult at many aspects Note =========================================== From a technological standpoint there is little doubt that a REBOL client would be an excellent choice. The real question is will the REBOL licensing scheme work for this project.