[npsnetv-developers] Re: Plans for NPSNET-V

[Andrzej K. <ak...@np...>]

----- Original Message -----
From: "Harney, James USA" <jwh...@np...>
To: "Kapolka, Andrzej USA" <ak...@np...>; "Savage"
<sa...@np...>
Sent: Monday, February 24, 2003 6:48 AM
Subject: RE: Plans for NPSNET-V


>   ****Back in Jan I was trying to do this, but kept getting exceptions
thrown on loading the 5-6 properties files Alan and Justin use in the
codebase when trying to load a j3d view in webstart.  All manners of cp and
proerty file placement hacking attempted.  Single xj3d.jar and multi-jar
tried as well.  Think the bootstrap method you've gone to is best for this
deployment option since once the session is intitiated with signed jars, you
can lazily download and cache on the client webstart app as needed.  As you
showed the other week, the GL4Java JCanyon demo is one of the best demos of
using webstart for real time 3D graphics.  Removal of graphics and just
running offscreen had no problem with sockets and self-signing the deployed
jars though.

     Yeah, the properties file problem pops up in NPSNET-V, too, when it
tries to download xj3d.jar for the first time (you can't add jars to the
system classloader, so NPSNET-V downloads the jar to the extensions
directory and loads it through a URLClassLoader).  Did you ask Alan and
Justin about it?  I'll take a look at the xj3d source today and see if I can
find a fix; if I can, I'll e-mail them and encourage them to use it.

     The only reason I would consider using WebStart is because of the
kernel update problem.  The problem is that one of the main ideas behind
NPSNET-V is a complete lie: the idea that the kernel and the basic property
classes (in other words, the contents of the jars that would be installed by
an InstallAnywhere installer) will never change.  In an actual deployed
system, based on a later, more stable version of the NPSNET-V kernel, I
believe it would be possible to maintain that kind of discipline--but for a
research project, it's just not worth the overhead, and I end up changing
the kernel and the property jars all the time.

     Using WebStart would provide a "free" way to ensure that users would
always have the latest version of the kernel and property classes.  The
alternative is basically using a nanokernel, or kernel loader, that would
provide much of the same function as WebStart: it would check some
configurable location for the latest version of the kernel and property
jars, downloading newer versions when necessary, using cached versions
otherwise.  There's some advantage to using the nanokernel approach anyway,
because it would be possible to tie it in to the standard update mechanisms
(i.e., you could upgrade the kernel at run time as soon as you discover a
new version of it--an option that WebStart doesn't provide).

>   *******I didn't realize til Ekrem showed me the other day that his XSFP
basic ship controller can be used for all ships with DIS, etc.  Will update
my example apps to refelect this week, and work with Ekrem on putting in
some of the basic dynamics stuff we've been doing in my thesis the last
month or so.  Think the one thing for an authoring standpoint that would be
really-useful/guiici would be to expose a particle system effects module.
Yumetech's impl has been up and down for use in the x3d/vrml loader, so I'd
say a NPSNET extension with the same params til there's is up would be a
major attractor since most cool effects are done with them after playing
super modeler-tool-master this quarter with Ken, Steve, Ekrem, and Fuzzy.

     I agree, that would be cool, and it might not be too hard to implement.
I'll have to take a look at the parameters that Yumetech's implementation
offers.

     --Andrzej