Page tree
Skip to end of metadata
Go to start of metadata

Time/Place

Attendees:

  1. Danny Bernstein 
  2. Andrew Woods 
  3. Ben Pennell
  4. Peter Eichman
  5. Mohamed Mohideen Abdul Rasheed 
  6. Bethany Seeger
  7. Jared Whiklo
  8. Aaron Birkland
  9. Peter Winckles
  10. Dan Field 
  11. Remigiusz Malessa

Resources: 

Sprint board: https://jira.duraspace.org/secure/RapidBoard.jspa?projectKey=FCREPO&rapidView=27

Agenda

  1. Round table check-in:
    1. What's working / what's not
    2. Availability for this week
  2. Are we on track to realize our sprint goals?
    1. core
      1. CRUD for containers and binaries.
    2. migration
  3. Sprint closing meeting


Notes

  1. Round table check-in
    1. Peter E
      1. Some of the design discussions difficult to keep up with, rate of PRs and changes
      2. Some local work Tuesday, meetings. Otherwise, available.
    2. Peter W
      1. Been working on bugs/fixes with ocfl client, been reworking paths in windows
      2. mostly available
    3. Ben P
      1. Finishing up ocfl obj session, locking. Reviewing other PRs.
      2. mostly available aside from meetings
    4. Andrew W
      1. need stakeholder testing of migration tool, it is becoming increasingly usable, needs docs
        1. want to see how well it will handle scale, multi-processing
      2. Suggesting looking at list of goals for the sprint
    5. Danny B
      1. Many parallel activities going on making things complicated, all layers working independently
        1. hopeful about getting read-write capability for at least some resource types
      2. Scattering of meetings, otherwise available. Can't get on early friday morning.
  2. Are we on track to realize our sprint goals?
    1. Core - these goals are our intent for the end of the year
      1. read/write involves versioning and transactions
      2. versioning is a little bit vague, are we going to support writing past versions? deleting?
        1. should be on target for writing them
      3. transactions
        1. should be decently well defined
      4. fixity
        1. some could come from OCFL, need to make decision of how to use the built in fixity aspects
      5. Many members
        1. Will need to get things further along in terms of all aspects of the stack working together to have a estimate of how this will ultimately perform
        2. There is a "real world tests" folder somewhere that has a many member script that could be used.
          1. Many Members Performance Testing
      6. services, index, persistence operations, and ocfl creation all currently in play.
      7. Basic content migration seems to be there
        1. right now it creates ocfl objects with turtle files
        2. will need to line up what persistence layout, look at that today
      8. Indexing
        1. PeterE - still in the early stages of planning https://docs.google.com/document/d/1yv_Tf_B4EqY8N1IDlm0avOt4mCF-5VuN0sOCtUyg_uQ/edit#
      9. Locking
        1. half isolated transactions - lines up with fcrepo4
        2. optimistic locking with merge
        3. ocfl client would not provide merge behavior
        4. is there a strong use case for merging?
          1. Peter's case does not have multiple clients writing at the same time.
        5. Andrew - Does fedora have a way of recognizing that object is in modification elsewhere, maybe communicate this?
        6. Ben - Not sure about doing this based off of persistence level info, versus http layer info like etag/last modified
        7. Transactions are hard
        8. going to start with last commit wins, work up to other types of optimistic locking
        9. at persistence layer, will focus on preventing simultaneous commits to object at same time
  • No labels