Show Posts
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.
Then again, the 56k people will kill you if you download that 4 MB JAR just because a tiny 4 KB sprite has changed
Quote
Once they find bandwidth is a problem, they might code their own update-API that is more efficient.
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
Quote
They end up writing something themselves. Just like we two both did.
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...
Don't always think about the server
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. 
Yay! Oh, here's some screenshots of JZIPUpdate running on Linux/Gnome:
Single progress dialog:
And for updating multiple archives:
