One thing I think might be getting confused here, is the usefulness of the webapp compared with how to handle the authoring jnlp. Having your own jnlp webapp will be very useful for the PRP. It will allow a installation of the PRP to be independent of our servers and releases. Regardless of how you handle the authoring jnlp that will be useful.
I don't see a clear way on how to correctly handle the authoring jnlp. If you want to be paranoid about curnit compatibility, then you would always use the same jnlp to author a curnit and use a runtime jnlp which has the exact same jars to run the curnit. This would mean once a curnit is started the author and user will never get bug fixes, or improvements. This would be the safest approach. If you want to get more of the latest changes, and deal with possible non-backward compatible changes, then you could always use the most recent authoring jnlp. But I don't know what you will do when one of those changes is not backward compatible. I believe the curnit will not be able to be opened by the authoring tool. A possible solution to this problem is have a curnit "upgrade process". This would run the curnit through a compatibility test and then a migration. I don't think there are any current plans to write the compatibility test or to figure out how to do a migration. More comments are below. On Tue, 2007-05-22 at 12:10 -0700, laurel wrote: > Hi Scott, > > Cynick and I are just now getting around to looking at this and are > finding it difficult to recall why we would want to do what you > suggest and create our own jnlp webapp. > > Some issues we are struggling with are: > a) How do we know that the authoring tool jnlp will work for the > specific curnit we are trying to author. The only way to make sure it will work for that curnit is to always use the same set of jar files. So if the curnit was created by the wise project converter, then you'd want the same set of jars that it was using. If the curnit was created from scratch by the pas authoring tool, then you'd want to always stick with the same jnlp. I know this isn't very good, but until we have curnit/pod compatibility tests and real versioned jars, there doesn't seem a good way to solve this. > b) Do we need a specifically time stamped jnlp to work with a specific > curnit? You don't need to use one, but that is the safest way. Specially when you are running the curnit in the school. > c) Why wouldn't we just grab the latest jnlp from > http://tels-develop.soe.berkeley.edu:8080/jnlp/org/telscenter/jnlp/au.. > every time That one will get updated all the time. So the curnit you created with it yesterday might not work today. Scott --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
