Time/Place

Attendees and availability:

  1. Danny Bernstein 
  2. Ben Pennell 
  3. Peter Eichman  
  4. Mohamed Mohideen Abdul Rasheed 
  5. Jared Whiklo
  6. Peter Winckles
  7. Andrew Woods
  8. Aaron Birkland

Agenda

Discuss and validate the following diagrams:


Questions:

  1. Do we see any weaknesses in the design?
  2. Is the current state of the java ocfl client sufficient to implement the design as it is? 
  3. Any significant performance issues anticipated? 
    1. Mitigation strategies?
  4. How do we handle versioning within a transaction? 
    1. We do not allow it (405)
    2. We allow it but reject subsequent requests  - ie the version creation request must be the last within a transaction
    3. Other possibilities ?

Notes

  1. Current OCFL client does copy and not move.  Move is riskier.
    1. mv will perform better
    2. Peter Winckles  can add a mv option, but it must be recognized that there is some risk.
  2. Checksumming: currently 2 checksumming operations are required by the client - a checksum could be provided to reduce that to 1  checksum calc.
    1. 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).
  3. 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.
  4. Question of versioning in a transaction should be deferred until later.  Either option above could work.