Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This proposal splits the high level storage interface into a read and write side.  There was some discussion about how to "stack" these interfaces.  One possibility that came up was having the wholistic Read+Write interface (Aaron's interface) be a singleton within the repository, through which all storage calls go, and some implementation of that might then send reads/writes to delegates beneath, which are read-only or write-only (Asger's interfaces).

One of the major questions that Asger's presentation provoked was whether versioning was still important to do at the datastream level, or whether it can be done at the object level.  We had a follow-on discussion about this.  The idea presented was: What if Fedora no longer held information about old versions in the DigitalObject class and in the stored FOXML?  In other words, these would be designed to work only with the current version of the components of the object.  If a datastream changed, a new version of the entire object would be made (and object-level version number would be incremented), and older versions of the datastreams would be retained only if storage was configured to do so.  While discussing this, one concern we landed on was that there would no longer be a manifest pointing to all versions of everything stored within an object.  We cut this portion of the discussion short in the interest of time.

To drive the high level storage To drive this work forward, we identified:

  • Lead: (smile) Aaron
  • Contrib: (thumbs up) Asger, (thumbs up) Dan, (thumbs up) Chris
  • Possible Contrib: (question) Lee Namba (re:Caching), (question) Others at FIZ (re:Versioning)

Semantic Web and Linked Data

...