Added by Turadg Aleahmad, last edited by Turadg Aleahmad on Jul 09, 2007  (view change)

Labels:

Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.

What we need to do for the CSCL workshop milestone.  Cynick wrote up a list initially and Turadg is working with him to keep it updated.

1. Fix something in sail core that is causing bean deserialization problems (Tony's bug). I don't have a good understanding of sail core so I'm a bit lost on this one. (This is OWL-257@issues)

2. Modify the curnit structure so that curnit jars contain information about its own dependencies. Right now the authoring tool is hard coded with certain steps and the dependencies required for those steps are not associated with the curnit. There is a discontinuity with the requirements for the runtime environment. How does the runtime know anything about the curnit other than its uuids? Uuids by themselves don't mean much. A universal look up registry may be an option. (OWL-209@issues)

3. Versioning of the curnit dependencies. This relates to #2.

4. Versioning of the curnit itself. This has an impact on saved session data. Any one version of a curnit may break compatibility with a previous version, thus causing saved data to be incompatible as well. Teachers and students should be able to get back previous work. This also applies to authors that change curnits that affect other users. (roughly OWL-246@issues)

5. Consider using Enlace's LOR to track resources and versions.

Pas Portal

Current demo. Gets wiped everyday at 1am.

http://portal-daily.encorewiki.org/

Meeting with Cynick

Plan for CSCL

Turadg will fix bugs in sail-core and authoring tool. Probably this will mean, reducing curnits to just one pod and postponing interpod relationships for a while.

Turadg will add into curnits some way to indicate their dependencies so the PAR and PLR can grab them. (Though this may take place in a portal constructing the JNLP before the runtimes are launched.) An important issue is that developers won't always want the latest version of the dependencies, because sometimes they'll break things. But they don't want entirely static versioning either, because then they miss out on improvements and bug fixes. So maybe the way to go is a history of automatically updating static versions, in which new dependency versions that don't work can be flagged and reverted from until an even newer version is available that actually works.

The next feature in the portal will be that the project record stores a sequence of curnit archives, uploaded either manually or by the authoring tool. Basically, this simple versioning will mean that a project has a URL on a Pas Portal and its version history is a linear sequence.

Some day, we'd like to make curnits into something like a "Flickr picture" which is much richer than just a JPEG. It includes discussion, tags, geolocation, privacy. In this scenario, a "curnit" would be a web resource and desktop client code would query it RESTfully.