Mauro Marinilli

Thank you for your time guys,
I hope I was helpful .
Take care!
Mauro

Thanks to you all guys, for the good time I had discussing together JNLP technology.
Have fun and enjoy your job!
Mauro

Yes of course!
Instead of placing your applet files your publish JNLP file(s) and JAR file(s), together with whatever you need more.
But wait; there is a subtlety: you have to add a new MIME typetoyour web server, that special one for JNLP files (see JNLP documentation or my book). Contact your webadmin to be sure they have such a MIME type added to their web server.
Cheers,
Mauro

Latha,
In the scenario I had in mind, only the first time installation is performed via a CD-Rom. Then, for further updates, or anything else you can refer to a remote Web site.
An additional advantage of this arrangement is that you prepare just one deployment version, and distribute it via several different media (web site, CD-Roms, DVDs, etc.). There some cases where the deployment is somehow private and clients prefers CD-Roms.
Cheers,
Mauro

Burk,
Both choices are possible. The JRE to be installed that is left on the CD-Rom, or to download it usually from the Web.
The book addresses both these situations.
Cheers,
Mauro

Yes,
you can use JNLP also for installing your app via local file system, or an installation CD-Rom as well. Of course, this is essentially for packaging simplicity (you use JNLP to bundle everything once, and don't need to create several different packages for the different deployment medium you use to distribute your app) but of course JNLP power is fully expressed only on a Internet (HTTP) connection.
Cheers,
Mauro

Michael,
I'm not sure but I don't think it will be possible, at least in the near future.
Thanks for your observation anyway, it sounds pretty interesting..
Mauro

JNLP still doesn't provide the ability to query for license keys, at least not explicitly.
What it does provide so far is the ability of downloading only the difference of JAR files.
Say you have an app that is composed of three JARs: JAR1-3. Then you post on your deploymen server a new version, that solves some bugs and the JAR1 need to be downloaded again with the newer version. If your deployment server can run servlets, you can use a JNLP server implementation that supports the JARDiff protocol.
At this point, say that the old JAR1 takes 850KB. The new one (JAR1a) is pretty the same as the old, just 1KB changes (it is actually a patch release). If your server supports JARDiff, then your clients will download only 1KB, not the whole JAR1a anew.
This is an example of an "advanced" service offered by a JNLP Server. Anyway, if you don't need such a feature, you can happily use a static web server, as discussed in my book or in any JNLP documentation.
Cheers,
Mauro

Burk,
There's nothing wrong with you, I have to writemoreslowly ( ) my postings!
An applet runs in an applet container, as a servlet runs in a servlet container, and so on. You can even build by yourself an applet container. Sun's AppletBrowser isn't a Web Browser but it does run applets.
JNLP Applet support shouldn't be misused, it is just a facility for easing the migration of "fat" applets into JNLP-launched applications. The proper deployment tool for applets still remains the Sun PLug-In. But for a category of "fat" applets (stuff like Oracle JInitiator, for example) the best _temporary_ solution is to deploy it via JNLP.
I hope to have clarified better the point.
Thanks for your patience,
Mauro

There are two typeof server support.
The simpler, just need to publish your files on any "static" web server (like those that host freely your HTML pages) and then point your web browser to them.
The "dynamic" support is needed when the advanced features of JNLP are needed, like the JARDiff protocol. In this latter case a servlet support on the server side is needed.

Originally posted by FEI NG:

I am concerned about performance. Would we see better performance than applet VS webstart?
Download time? and compatibility with browsers?

Your question is fully answered in the book (see for example page 56 for a general discussion of this issue) I'll try to condense a lot, I hope Idon't I miss anything of important:
- Performance: yes, there a little slowdown, because the JNLP Client is an extra application running on its own..
- Download time: Roughly speaking is the same as the applet version only the first time the JNLP application is installed. Then it is cached locally so no other download is needed for any new session, though the JNLP Client needs some extra download time at first, of course.
- Compatibility is fully ensured with the major browsers.
Another parameter that you didn't mention (but that turns out to be quite important) is the impact on the end-user of the deployment technology. JNLP is much better than applets. That because usually you use it for thick application, not for 20KB-some applets. In the case of large applets, the browser hangs frustrating the user, while JNLP application of the same size leave full control to the programmer that can insert banners, messages and even split up the installation in several sessions. Basically JNLP allows for more control on complex/large deployments. This is essential for the end user.
Thanks,
Mauro

As a rule of thumb,
use applet on the Internet, as lightweight, freely accessible components.
Applications (thick clients) can be used in an Intranet environment or deployed over the Web.
Essentially JNLP can be used for applications that substitutes thick applets.
Do not use JNLP for applets in the long run! There is the good old Sun Plug-In for applet deployment.
Cheers,
Mauro

Well,
Actually I was meaning the current JNLP files themselves. For JNLP client configuration there are properties files stored in the guts of the Java WebStart directory, but Sun discourages any edit to them, so far.
There are some JNLP IDE so far, some free.
In a following post I'll give some fresh URL,
Cheers,
Mauro

Hi Russ,
You'll learn all the basic JNLP feature (like using or not icons and desktop shortcuts, etc.) following the links given in the other topics.
Have fun with JNLP!
Mauro

Burk,
It's OK. Simply the JNLP mimics a bit the Applet container, pretending to be an "applet browser".
At page 284 of the book the magical "applet-desc" tag is described and some code is given.
Anyway, the support for applet is "shallow" in that it has been included only for easy migration of old "fat" applets into JNLP applications.
Anyway, the best way to use JNLP is through thick Java client applications.
I hope this clarifies the issue a bit..
Cheers,
Mauro