Time/Place
- Wednesday, Sept 18, 2019
- Time: 12:00pm Eastern Daylight Time US (UTC-4)
- Audio/Video Conference Link: https://lyrasis.zoom.us/my/fedora
- Dial-in:
+1 408 638 0968
+1 646 876 9923
+1 669 900 6833
Meeting ID:
812 835 3771
- Dial-in:
Join fedora-project.slack.com on the "sprints" channel
Attendees and availability:
- Danny Bernstein
- Ben Pennell
- Peter Eichman
- Mohamed Mohideen Abdul Rasheed
Jared Whiklo- Peter Winckles
- Andrew Woods
- Aaron Birkland
Agenda
Discuss and validate the following diagrams:
- Transaction Aware Persistent Storage Layer (diagram)
- Flow Diagram Adding Binary to Existing AG
- Other docs:
Questions:
- 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 ?
Notes
- 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.