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:
1. 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
1. Such an endpoint should implement minimal LDP interactions
Use HTTP over OCFL to test:
1. Performance bottlenecks
2. Scale viability (e.g. NLM migration)
3. User expectations, ergonomics

...

Proposal: no change to the Fedora API spec in 6
We will either:
1. align code with the (as-yet-to-be-ratified) side-car specification
2. 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)

Page tree