Yet another ZIP/JAR update system

Shared Code
#1

I’ve been reading the JGO forums for over a year now and I’ve been developing something similar to Skippy’s Updating API without JWS. My system started as part of Wurm Online, but I figured it might be better to release it to a wider audience.

Some key features:

[]Updates ZIP and JAR files over plain HTTP 1.1, support for proxies provided by Java runtime
[]Minimal data transfer through incremental updating and compressed data transfer
[]Low demands on server: maximum of two HTTP requests for full check/update
[]No application/code required to run on the server (except web server software)
[]Transparently updates sealed and even signed JARs without invalidating signatures or breaking the chain of trust
[]No need for clumsy external versioning information like with JWS, just one small compressed index file per ZIP/JAR archive

So, enough talk:
http://jzipupdate.sourceforge.net/

Comments, reviews and criticism always welcome :slight_smile:

#2

Although 40 views/week and no comments don’t make me feel too cozy :wink: , I’d like to point anyone who tried using JZIPUpdate and got an exception labelled “Found CR in line but not followed by LF.” to the latest release 0.9 which fixes that issue. Thanks to Markus Persson for reporting that bug, and blame on me for causing it :-[

Did anyone at all from JGO give it a try yet? Skippy’s NetUpdate seemed to attract quite some audience…

#3

Let me jump in here, then :wink:

Let me start by saying I truly like your API, that finally brings some intelligence into the updating process, by doing a per-entry update of archives.

But it’s the same as with my API: people want standards, so they use WebStart. They will notice that it does the job in an acceptable way, and stop looking for something better. So be it.

Once they find bandwidth is a problem, they might code their own update-API that is more efficient. Chances are small they search for an existing API, chances are smaller they find yours, chances are tiny it fits precisely what they want. They end up writing something themselves. Just like we two both did.

So your user-base (devs) is kinda zero.

On a side-note: you have done that stuff with multi-part HTTP-responses pretty good. But well, these days HTTP- requests are cheap. Just look at what bunch of requests a forum generates. Compared to that for [most devs], the advantage of saving a few cpu-cycles by using multi-part, is outweighed by the disadvantage of the pre-processing step: indexing your archives everytime you upload an updated version. Too much hassle.

So only if you’re short on bandwidth/datatraffic… the majority of the visitors of this forum isn’t: small app, even smaller number of downloads.

As a wise man once said:
There is nothing more to say.

So much for the highly anticipated request for feedback. :wink:

#4

Oh, and we live in a world where screenshots matter!

Post a few good lookin’ screenz and dig your way through the heap of replies.

#5

[quote]But it’s the same as with my API: people want standards, so they use WebStart. They will notice that it does the job in an acceptable way, and stop looking for something better. So be it.
[/quote]
Then again, the 56k people will kill you if you download that 4 MB JAR just because a tiny 4 KB sprite has changed :slight_smile:

[quote]Once they find bandwidth is a problem, they might code their own update-API that is more efficient.
[/quote]
Unless you go binary with a custom protocol, I don’t see much room for further space optimizations. And rolling out a custom protocol will open a can of bug-eating worms for sure. That’s why sticked to good ol’ HTTP 1.1 :slight_smile:

[quote]They end up writing something themselves. Just like we two both did.
[/quote]
Yeah, but the more update APIs there are, and the more feedback they get, the higher the chance that one of those APIs will become useful to a larger audience.

[quote]So only if you’re short on bandwidth/datatraffic…
[/quote]
Don’t always think about the server :slight_smile: The incremental updating also benefits the client, even on broadband it’s a difference wether I download 4 MB or 4 KB. Even more so for narrowband.

[quote]So much for the highly anticipated request for feedback. :wink:
[/quote]
Yay! Oh, here’s some screenshots of JZIPUpdate running on Linux/Gnome:

Single progress dialog:

And for updating multiple archives:

#6

I haven’t tested it myself, but I’ve seen it in use via Wurm. As soon as I saw your post here I bookmarked the site and intend to use it for my current project, though I’m a ways off from that stage yet. Just wanted to let you know your post wasn’t for nothing :slight_smile:

#7

Yeah, Webstart’s always had that as a core feature.

So, if you ask me, the reason people don’t really care is that they didn’t, in fact, have a problem in the first place - if they wanted this, they just had to install the free servlet that Sun provides, or else implement the protocol that sun documented (I chose the latter, since I don’t use no steenkin J2EE :P).

Yes, standards are good, but not THAT good - people will often avoid them unless the features / reliability are quite close. But if your API is offering very little in addition, then most are obviously going to go for the standard (especially webstart, which you can expect to get 1000x as much testing etc).

/me notes, however, that webstart development and bugfixes from sun are so slow / infrequent that in this case any fully-working alternative is likely to receive serious consideration if the author shows even half an inclination to, oh I don’t know, FIX CRITICAL BUGS.

So … maybe you should explain how this is any better than webstart?

#8

Re: Standards - its not so much that, I could make an updater that used the JNLP standard (or just use OpenJNLP). The point is, if you’ve got java atm then you’ve got the webstart implementation.

Kev

#9

The big problem I’ve always had with webstart is the bootstrapping problem, not how it actually works. All I want is someone to write a native Webstart bootstrap that’s like, under 300kb or something, and downloads the VM the first time it’s invoked and installs it and then gets on with downloading the rest of the game.

On a related note has anyone seen how Tribal Trouble updates itself? (Uses subversion and a built in Java client). Fantastic.

Cas :slight_smile: