Design

1. Driving principles:
   1. Minimizing change to the user via the API
   2. OCFL-isms not bleeding into Fedora API
   3. Rebuildability
   4. Compliance with OCFL
   5. Retain URLs of migrated Fedora resources
   6. Performance
   7. Reducing complexity of implementation

Fixity service

• Scheduled fixity service:
  • Probably not part of the core,  run as a separate service possibly controlled via camel.
• https://docs.google.com/document/d/1bTM0MEoaa88IFaT1zR6YlpFAnLOshjEIKi7miFMm620/edit#heading=h.9zyqk9cxc88

Transaction service

• No definitive decisions made.
• 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.

Query endpoint

Proposal: Query endpoint should support the following use cases:

• List all resources

• List resources by mimetype

• List resources by parent

• List resources by mimetype, parent, and modified date (<>=)

• List resources where modified  <> x date.

https://docs.google.com/document/d/13C_UhB37docTd8ZTD1ZSKuFhX6q9_3Boo67hjUC2YyM/edit

Versioning

1. Support for both:
   1. version an object on-demand (manual versioning)
   2. version an object on-change (auto-versioning)
2. Support for toggling auto-versioning on/off
3. Note: Actively edited objects not captured in an OCFL version directory, but rather in a "cache" directory below the object root.  Entries to be indexed in the database .
4. There will be a one-to-one correspondence between OCFL versions and mementos.

Bulk ingest

To flavors of pointing a Fedora instance at an OCFL backend.

1. via OCFL
2. via Fedora OCFL 
   1. ie "content/.fcrepo" aware

https://docs.google.com/document/d/15QwmyNFMopJW4MHxQNTiOGh_WXsOPr9-yzctGLCgT5k/edit

Import / Export   (Migration)

• https://docs.google.com/document/d/1nvUDar1DbexdU3oTRGxzcZGG3qxsD2HWQbGyyRJIgDE/edit#

Mapping between LDP and OCFL

Opt-in model

1. Fedora resources may be created with an optional "archive" interaction model provided via headers.  

2. New resources created via POST or PUT to the archive will be LDP contained by the archive and will be stored within the OCFL object representing that archive.

3. If a resource is created without the "archive" model, new resources created via POST or PUT will be LDP contained by the archive, but will be stored as separate OCFL objects.

Notes/Implications

1. At creation time, you establish what you want and then stay in that model. Changing the model would require additional migration tooling.
2. Requires 3 interaction approaches: atom (implicit), archive, part (implicit)

Architecture

1. Retaining HTTP layer of existing Fedora codebase
2. Replacing ModeShape persistence with OCFL storage
3. Optimizing reads/lookups with an internal database
   1. proposed database model: https://docs.google.com/document/d/1MsMfhae3thmNdoFtnTUnII3mr_-OkllRs9PvgnY1fDY/edit

Scaling

• stateless Fedora instance(s) will scale horizontally
• database can be clustered and/or moved to cloud  database service(RDS,Aurora,etc)
• start with file system, scale out to  cloud object store (s3)

Performance

1. 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).  No loading of modeshape nodes required.
2. Ingest speeds: 

ModeShape replacement

OCFL persistence

1. Support for both OCFL objects:
   1. created by Fedora
   2. pre-existing, created by another application

Fedora-specific details

1. /content/.fcrepo directory
2. Hashing (SHA256) on LDP path of resource