I agree that we should work on an alternative to WebStart. I'm not convinced this work should start immediately (at least at CC). We have just hired a person to keep and update the schedule of the work CC is doing and plans to do, with that picture in hand we should be able to figure out where to fit this in.
The design I would use for this would be to use WebStart to bootstrap the process. This way we don't need to mess a few issues: - handling proxies - handling launching this thing from different browsers. - the only thing required to run our app is an install of Java. So to launch an app from a web page we still would use a jnlp file but it would just have a single jar dependency. That jar would have the code to find our cache, and launch our WebStart alternative from that cache. I'd guess this jar will less than 5k. We can avoid the various jardiff issues a couple of ways: (1) don't use jar versions (2) use versions but rename the jar each time the version changes. The second has the advantage of not checking for updates each time. As Sam described our app would store the cache in a normal location for the platform (Application Support for example), and the cache could be updated by a normal application installation process. We will have control of the download process so it will be much easier to do p2p cache sharing. Another issue we could finally deal with is caching the content and the code in the same place. To be realistic this isn't a small task. CC has done something similar twice before. Once in the MAC project with a piece of code I created called "workspace". And once at the beginning of the TELS project Ed Burke created a caching classloader which is in the "loader" project. The "workspace" code suffered from not integrating with web browsers, and not dealing with proxies well. The "loader" project suffered from not efficiently downloading files. If we bootstrap from webstart as described above, I think the task is reasonable and maintainable. I think we can also implement it from the start as a independent open source project that is a replacement for webstart. Scott Sam Fentress wrote: > On Thu, Jan 8, 2009 at 2:28 PM, Stephen Bannasch > <[email protected] > <mailto:[email protected]>> wrote: > > > We need to use a different distribution mechanism than the JWS > built into Java. > > I'm thinking we should deliver a Java application that implements > it's own version of JWS that works better. > > The user experience could be MUCH better -- and it desperately needs > to be much better. > > > Another benefit of having an alternative to Web Start might be that we > could provide a much nicer off-line installation. > > Currently, to install our software off-line in such a way that JWS can > get updates in the future, we have two solutions: start up a server on > the local computer (or a USB stick) that mimics jnlp.concord.org > <http://jnlp.concord.org>, which is clunky, or have an administrator > push out entire Web Start caches, which not only will wipe any > existing Web Start caches but is also frequently impossible because of > inabilities to make bulk modifications to user's home folders. > > If our software could be installed in a standard application location > (which would make it very easy for schools to install and push out), > yet still retain the ability to make Web Start-like updates (perhaps > with a scheduled update period, so that the administrator could do it > with their permissions?), our distribution process would be many times > easier. > > However, this is easy for me to say because I don't know what would go > into creating a Web Start alternative... ;) > > Sam > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SAIL-Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/SAIL-Dev?hl=en -~----------~----~----~----~------~----~------~--~---
