Re: How to copy one jar inside another
Mark Space wrote:
(..Web start)
True. If you read my original post, you'd notice that I specifically
said webstart isn't an option.
I want to clarify some things I am confused about, before
abandoning the possibility of web start.
..I don't want to get into details, but
basically, I have no web page to start from,
Free web pages today are a 'dime a dozen'.
Geocities* is still accepting memberships,
Google is offering space with email addresses
(AFAIR), I was offered some form of web space
with JavaKB when I signed up for an account
to post to usenet, most ISP's will offer a basic
web space to clients.
Here is my tacky old web page from about '99.
<http://www.geocities.com/SunsetStrip/Palace/9295/index.html>
I had never bothered to check if there was any
impediment to web start off geocities.
..and don't want to set one
up,
The sign up generally takes around ten minutes,
the web page that launches the app. might be as
simple as..
<html>
<body>
<h1>Download Application</h1>
<p>Download our <a href='thelaunch.jnlp'>application</a>.
</body>
</html>
The only hitch is whether the host serves the correct
content-type for this file. Usually they do, or it is a
trivial addition to a config. file to support that.
..plus HTTP connectivity isn't guaranteed anyway.
This is the thing that most confuses me.
Whose connectivity? Yours or the client's?
If yours, then I have successfully uploaded
HTML/JNLP/Jar files for web start apps.,
using internet cafes and the computers at
the local library.
The client's connectivity? I can see that might be a
problem, which is why I mentioned 'web start off disk'.
..Yet you go on to mention (somewhere I cannot see
now) that distribution might be by 'email-out'.
That strongly suggests the clients have HTTP connectivity
enough to receive the initial application resources. If the
JNLP launchfile is appropriately configured (all resources
marked as eager, and the offline-allowed attribute specified)
the web start launch can have the same initial effect.
The entire application being downloaded and cached on the
client system - with the added advantage that each time
the app. starts thereafter, it will check if the internet is
available, if it is - check for jar updates, if there are any,
it will download them ready for next launch, and in the
meantime, whether there is a connection or not, JWS
will launch the cached copy of the application.
It seems (with a litle extra effort on your part) the ideal
way to distribute this application.
In the email-out, simply link to the 'download' page.
The client can decide whether they are interested
in the application, before suffering any significant
download, and if the decide they want it, the app.
can be entirely downloaded with a single click
(barring prompting for security permissions, or
choices for menu item/desktop shortcut).
...I'm going to have
to deliver the .jar physically ..
Unless I missed something, there are only two options
for remote, widescale distribution - disk (floppy, CD,
DVD) or HTTP (email, the web..). I cannot see how
the disk could work out cheapest, but might be an
option for systems with no external connection at all.
So that leaves HTTP - and web start was initially
defined for the web page medium (though as mentioned,
it can be adapted to work off disk).
You seem to be working very hard to avoid it, and
with less effort, could possibly set up a simple web
start based example.
..by some other means, which I'm trying to
figure out.
...hmmm. It seems to me that 'reinvent web start'
is what is happening here.
Some thoughts for you to ponder.
--
Andrew Thompson
http://www.athompson.info/andrew/
Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-setup/200705/1