...
- Lead:
Chris - Contrib:
Dan, Andrew, Asger
High Level Storage
Aaron presented his proposal for a high level storage interface for Fedora, describing the motivation and use cases that it enables.
This proposal was generally well-recieved.
During the discussion, Aaron identified the need to have Fedora's internal datastream locations (stored within the FOXML, for pointing to managed content) be specific. That is, rather than "pid+dsid+dsVersionId", they should be an internal location that means something to the underlying storage. Action: Validate this with Aaron and add as a JIRA issue.
We also touched on what it would mean to make this interface compatible with asynchronous read/write use cases. For reads, if Fedora cannot find the content immediately, a 503 http respons and a retry-after header should be sent. It is unclear exactly what should be happening at this level to support such use cases, but one possibility that was mentioned as to have the operations return a Map of name-value pairs as a possible extensibility point.
The ideas around high level storage are still forming, and are inspiring some ideas about caching and sending updates to modules in Fedora in pluggable ways. Asger presented a follow-on proposal:
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).
To drive this work forward, we identified:
- Lead: Aaron
- Contrib: Asger
Semantic Web and Linked Data
...