Attendees and availability:
- Danny Bernstein
- Ben Pennell
- Peter Eichman
- Mohamed Mohideen Abdul Rasheed
- Peter Winckles
- Andrew Woods
- Aaron Birkland
Discuss and validate the following diagrams:
- Do we see any weaknesses in the design?
- Is the current state of the java ocfl client sufficient to implement the design as it is?
- Any significant performance issues anticipated?
- Mitigation strategies?
- How do we handle versioning within a transaction?
- We do not allow it (405)
- We allow it but reject subsequent requests - ie the version creation request must be the last within a transaction
- Other possibilities ?
- Current OCFL client does copy and not move. Move is riskier.
- mv will perform better
- Peter Winckles can add a mv option, but it must be recognized that there is some risk.
- Checksumming: currently 2 checksumming operations are required by the client - a checksum could be provided to reduce that to 1 checksum calc.
- Peter Winckles can add support for providing a checksum upfront thus limiting the number of checksumming operations per ocfl version to 2 (once on transmission and once on ocfl version creation).
- If we need to the ocfl client to support transactions down the road, the impact to the fedora code base will be minimal: let's not worry about it now.
- Question of versioning in a transaction should be deferred until later. Either option above could work.