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
Boris,
>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.