> -----Original Message-----
> From: Wayne Wilson [mailto:[EMAIL PROTECTED]]
>
>
> John S. Gage wrote:
> >
>
> > Apparently, David and I, working in very
> > different areas, have had essentially no problems
> whatsoever delivering
> > the JVM with our applications. Wayne, on the other hand,
> appears to
> > have had problems...perhaps because his client base is much
> larger and
> > more diverse.
> >
>
> The reason behind this is straightforward enough to
> understand: scale and approach.
>
> To improve the user interface, we have thought about
> adding javascript (not the same thing as java and not
> dependent upon java), but due to various versions of
> javascript in various browsers, this can be challenging.
Where I work we tried this. The need to support various versions of IE, and
also Netscape made this problematic. Definitely straight HTML delivered
with a server side scripting capability is a big plus. We use Coldfusion
for
this, and some ASP, but it's the only way to ensure all clients work, in my
experience.
> Our constraints are as follows:
>
[snip]
>
> - jvm support at the browser and OS level can be safely
> assumed to not exist anymore. This allows one to use
> dynamic JRE downloading and java webstart to configure
> client machines with known versions of the jvm and
> application.
This is exactly the approach we're starting to take. Our first
delivered applet with JDK 1.4 (beta) will be a web charting
application (simple bar/line/pie charts). I'll keep you posted
on how it goes.
> There are issues with the latter situation: Because
> Microsoft will no longer load a jvm with IE or the OS, JRE
> downloads on MS platforms will be required. For folks
> connected to high speed networks this will not be a speed
> problem, but it will present to everyone a user interaction
> problem. For example, just rolling out a SSL protected web
> application caused an overload of user support calls when
> the certificate we used was not a standard one and a new
> user dialog to download and accept a new certificate was
> presented to end users. They considered this to be an extra
> burden and an unreasonable expectation on our part.
We get the same "snivveling", and one way we deal with it is that
we explain to the users (in the case of Webstart and the JRE), that
this is an ongoning requirement, and a faster way to keep the
desktop upgraded. Our users tend to like that.
Our department supports about 600 workstations, but I've found at
previous jobs that the problems are no different than supporting 1,200
workstations. 6,000 is quite a jump, but I suspect if users get
installations done more quickly for the price of a few mouse clicks, then
they'll be happy *overall* (you never make everyone happy).
>
> Anyone seen the JRE download and installation process?
I work with it regularly.
We're getting into it now, organizationally. The biggest problem I've had so
far
actually is the complaints by users that have to do a little
extra work. I'm counting on Webstart to help alleviate this, and
when our clients see what functionality we can deliver with the JRE and
Webstart, I think they'll buy into it.
Doing incremental upgrades through Webstart off our Intranet server is very
attractive.
> of workstations. Personally visiting each workstation is
> out of the question, so that leaves some sort of
> non-intrusive or transparent and reliable network
> distribution method. I don't know of one yet.......
Another thing I'm going to try out is a silent installation of the JRE 1.4.
I hope this helps greatly.
> That is why MS .NET and C# java replacement activities are
> so important to the long term future of java on the desktop.
> IF MS succeeds and jvm distribution remains a user support
> issue, then java on the desktop will only be viable to those
> with tight control over desktops or very smooth end users.
I fear you may be dead on here . . .
Richard Schilling
