On Fri, 2003-11-07 at 02:39, David Forslund wrote: > I agree generally with this statement. However OpenMap, for example, > doesn't require this if you use it on the serverside > (much like ArcIMS is typically used).
Yes, that's (mostly) how we use ArcIMS. I don't recall evaluating OpenMap on the server-side only - perhaps we overlooked that - we must revisit it soon. Anyway, ArcIMS is working well for us but it is a barrier to transplanting our system to other settings, since everything else is open source. > 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. Yes, we aim to be both JavaScript-free and Java-free on the client side. The GIS aspects are the only place where this has not been possible. I should say, we aim not to require JavaScript. If it is present in a known browser implementation then we are starting to use it a bit, very selectively. for some convenience functions. But if it is not available, everything still works. > 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. Every time there is a MS Windows virus outbreak the network admins lock down all ports except 25 and 80 on our WAN routers and firewalls. Well, that's an exaggeration but it often happens. > 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. The battle is getting IT support staff to recognise that a recent JVM should be part of their standard PC operating environment. Tim C > 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: > >> > >>> > >>>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. > >>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. > >>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). > > -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0
signature.asc
Description: This is a digitally signed message part
