Re: [Openjnlp-devel] Background downloading of newer versions

[Kevin H. <ke...@na...>]

On Thursday, May 9, 2002, at 01:57 , Mario Cormier wrote:

> Are there any plans to support background downloading of newer versions 
> when
> there exists a working version in the cache?  For instance, in section 
> 1.2.2
> of the spec it says "a JNLP client can download an updated version in 
> the
> background, while the already-downloaded version is being used".  (They 
> seem
> to imply that you need to use the version-based protocol to be able to 
> do
> that, but I fail to see why you would NEED it.)

That's exactly how I read the spec as well, and my admittedly limited 
testing with JWS seems to show the run current/download new behavior is 
only for version-based resources, not basic.

If you think about it, it does make sense. You don't want the background 
download to modify the jars of the version you're running. The way I 
view things a basic (unversioned) resource is just a special version. So 
downloading out-of-date jars is updating jars within that version, not 
getting a different version. You'd have the same scenario if you're 
using foo.jar version 1.2 and it's out of date, but still version 1.2.

> I think having support for that would provide much faster startup times 
> when
> the network is slow.  I could implement it myself, but I think it might
> require small changes all over the place so if it's already in the 
> plans or
> if someone is already tackling this issue, I suppose I can wait.  Any
> suggestions on how to go about this?

I've been giving thoughts as to how to add versioned resources to 
OpenJNLP. I think versioning needs to be implemented before any 
background upgrading can happen.

My thoughts on versioning so far are:

1) Multiple versions of an app can co-exist within the same cache entry. 
This means multiple versions of the same jar within the "Resources" 
directory. I think attaching the version-id to the resource file name 
will accomplish uniqueness. The basic version would simply be the 
resource name.

2) Basic (unversioned) resources are considered a unique version.

3) Updating an out-of-date resource does not change the version.

4) The version of a resource used for an app is determined by the jnlp 
file, which may also be versioned.

5) I think the entry.xml file would get updated to move the <resource> 
and <nativelib> entries inside a <version> tag or somesuch. A possible 
example is:

   <entry vendor="Foo" title="Bar">
     <version id="1.2">
       <resource href="http://www.foo.org/bar.jar" version="1.0" 
modtime="12345" />
     </version>

     <version id="1.1">
       ...
     </version>
   </entry>


I think it needs more thought/discussion before any implementation is 
done. But most importantly I'd like to get a new release of OpenJNLP 
done first. There are already a lot of big fixes/changes "in the can" 
that should be rolled out as an official version.