improvements in JWS for java 6

Networking & Multiplayer
#1

http://www.jcp.org/aboutJava/communityprocess/maintenance/jsr056/56changes.html

best parts are :

  • download service allowed to access other resources than the ones referenced in the jnlp file, as long as they are reletive to the codebase
  • ask the client if he wants to install an update, or keep the current version
  • start fast, and check for an update in a background thread (avoid the 5 seconds initial lag).

Things still missing : an API to trigger client updates (like : refering to a new jnlp file) from inside the app. That would allow for example to have version N of a game accessible from everybody and version N+1 accessible only for some users when certain conditions are met (e.g. if their hardware supports new features, of if they are registered to always have the latest version).

Lilian

#2

They really need a way of specifying the update priority. E.g. “This is a security update recommended for all users.” vs. “We fixed a small typo in a feature you never use and the download is 200MB”, or even “This is an experimental version that contains some new features, it has received limited testing”

Then of course I want to be able to tell the Web Start client, ALWAYs get security updates, but ask me about others.

I’m not sure how well it will work, since someone could claim an update was for security purposes but really it was a lot more.

#3

That would help a lot from my point of view. Add a fourth value to the “check” attribute of “application driven”. When this attribute is set, JWS would only check for, and execute, updates when requested by the application. That way, I could set my own policy for when my server is pinged, and when my application is updated.

JWS seems way to Enterprise oriented for use on a home machine. Its great if you want to keep all the legs of the corporate centipede marching in step. But on a home machine, “if it ain’t broke, don’t fix it” seems to me a better strategy. Like c_lilian, I would like my users to be able to stay with the familiar version until they are ready to move on to a new one.

#4

[quote=“Timedancer,post:3,topic:25343”]
It says they fixed that part.

#5

It’s not enough enterprise oriented… sometimes in enterprises you plan a migration path (office 1 keeps version N, office 2 swtiches to N+1…) and have the users switch automatically their application (it’s not up to them to say they’re ready). This migration path is generally preceded by the presentation of version N+1 (some users get lost really fast…) and this is why it’s not always a “big bang” switch.

In that way a API for integrated migration system would be really nice, and a good seel point for JWS for reluctant companies.

Same thing could then be applied to games (of course with the ability to revert to the previous version, again from inside the application).

Lilian

#6

[quote=“swpalmer,post:4,topic:25343”]

As I read it, the new feature allows you to abort the update every time you start the application. That could become a pain. Allowing the application to determine when updates are even checked for, never mind actioned, would give developers much more control over the process. At the moment, JWS assumes one kind of Enterprise approach to software distribution. Everyone updates in lockstep. And as c_lilian points out, not even all Enterprises want that.

#7

Another thing that needs fixing is when you click a .jnlp file and the .jar’s are on a server that does not support resuming, the percentage or downloaded data is not shown, it remains at 0 until jars finish downloading, while this happens it gives the impression that no data is downloading or the jws has crashed!

if the percentage can’t be shown the amount of data that has been downloaded should at least be shown so the user knows that something is downloading.