(much like ArcIMS is typically used). We have had almost as much trouble, though, dealing with variations in JavaScript in the browser and
you will find many web sites that have custom JavaScript for each browser they support. We've recently had a problem
with the JavaScript interface to an ArcIMS server, too, because it makes some assumptions that may only apply on
an intranet. We rely heavily on Java on the server side, and no Java on the client. We give up functionality, in many cases,
but people seem more comfortable with this solution, and this option is getting better all the time with XML, etc. capabilities.
I think Java WebStart is a good way to drop a Java app onto a desktop and maintain it. The fact that MS doesn't provide
a JVM is actually good, because you have much more control over compatibility without it getting in the way. Firewall issues
are always a problem. To have a distributed app working between enterprises, we have to negotiate with all the parties
for a port (or ports) for our application. Coming over port 80 (or 843) is not a good option because this doesn't really help security. This
really is a more general issue than the JVM problem, however.
Installing a JVM on a system today enables the plugins for the browsers pretty much automatically, so once this is done, you are in
good shape.
We also have quite successfully use InstallAnywhere, which basically makes the JVM disappear, because it is delivered with the app,
if needed. It is a waste, however, if each app on your desktop has its own JVM.
Dave
At 08:13 AM 11/6/2003, Heitzso wrote:
Re Java applet, browser side. There's going to be strong opinions on this, probably on both sides. But at the CDC we made a strong stab with Java applets for several years and it never stopped being a problem. The last major push was with DataFerrett that was co-developed with Census. Census eventually wrapped it up as a standalone app and made that their recommended way to download and run the app.
Some bad assumptions:
- All users will have a java enabled browser, or ...
- if a user doesn't have a java applet their company/gov/agency will let them download and install a java jvm for their browser, and ...
- the jvm supported by a user's browser is version X.X or above.
These factors can be controlled for in an intranet but not out in the world at large, particularly when dealing with tightly controlled user systems.
(following is a paraphrase of an old song) "Oh trouble, trouble won't you set me free? I've seen your face and I don't want to see it again."
Heitzso
Wayne Wilson wrote:Tim Churches wrote:
I am wondering how this evaluation can be made. We are faced with similar problems in considering the use of java webstart. Not so long ago, we had hoped that advancing browser technology would solve this problem, but Microsoft essentially killed that plan. Java is now essentially decoupled from the browser. On the Macintosh we waited for many years for Apple and Sun to deliver a well supported java with the OS and now it's happened with OS X just in time for java support to be completely dropped by Microsoft.
But if you are looking for a fairly fully-featured map browser which can run in a browser (if you have Java), then it looks like the goods. We plan to re-assess in a year or two, when we can rely on users having a fairly recent Java VM installed.
That essentially leaves a web initiated, JRE install as the only viable option for ensuring java on client platforms that one does not control.
I wonder if that option is at all viable? If it is, then what is the set of circumstances that would allow one to conclude it is ready to use?
Some factors I can think of:
1) Speed of CPU
2) Rev level of OS (i.e. Windows XP or Mac OS X or linux kernel 2.4.x)
3) Desktop image policies (i.e. user can't install software)
4) Network firewall port restrictions. (We recently encountered a situation at UCLA where client browsers could not specify port numbers which lead to a failure of our clincial trials software).
