...
- Provide new implementation of fcrepo-kernel-api that interacts with OCFL persistence
- Interactions with OCFL persistence should initially take advantage of the JHU OCFL client
- For pre-existing OCFL storage hierarchies, Fedora-imposes the following constraint:
- The OCFL storage hierarchy must have a single, consistent "ocfl_layout" (i.e. the storage path mapping algorithm must be determinant)
- Many members: performance should improve significantly since list of members will be supplied by a database index (which should support a degree of in-memory caching)
Deleting tombstone of OCFL Object purges the Object
Deleting tombstone of "constituent part" is not supported (405)
Prototyping proposal
- Expose JHU OCFL client functionality with minimal HTTP endpoints
- Such an endpoint should implement minimal LDP interactions
- Use HTTP over OCFL to test:
- Performance bottlenecks
- Scale viability (e.g. NLM migration)
- User expectations, ergonomics
...
- Proposal: no change to the Fedora API spec in 6
- We will either:
- align code with the (as-yet-to-be-ratified) side-car specification
- leave HTTP API unchanged while introducing the possibility of auto-versioning on transaction completion
- Potentially store updates within a transaction in a "txn/" directory at the sibling-level with OCFL version directories
- Support actions on multiple OCFL objects within a single transaction
Deleting tombstone of OCFL Object purges the Object
Deleting tombstone of "constituent part" is not supported (405)