Time/Place
This meeting is a hybrid teleconference and slack chat. Anyone is welcome to join...here's the info:
- Time: 11:00am 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 "tech" channel
Attendees
Part 1:
- Danny Bernstein
- Peter Winckles
- Jared Whiklo
- Bethany Seeger
- Thomas Bernhart
- Aaron Birkland
- Andrew Woods
- Ben Pennell
- Ben Cail
- David Wilcox
- Peter Eichman
Agenda
- Announcements
- Proposed PersistentStorageSession interface changes
- What is wrong with the current approach?
- Having two separate layers responsible for creating FedoraResources seems confusing.
- Passing a mutable FedoraResource to the persistenceStorage for create and update could be confusing.
- What would improve things?
- immutable FedoraResource
- fedora resource is a view of the resource on disk - doesn't provide all details unless they were requested
- implementations are responsible for throwing exceptions when particular details (such as a binary stream or the server managed triples) are not provided by the view.
- immutable FedoraResource
- For reference: proposed additions to the persistence API
- What is wrong with the current approach?
- Fedora 6 and OCFL: managing active updates
- What are we planning to implement?
- How do we want to implement it?
- Consider multi-object transactions
- Thinking about object stores in the cloud (S3, etc)
- <add topics here>
Tickets
In Review
Please squash a bug!
Tickets resolved this week:
Tickets created this week:
Notes
Fedora 6 and OCFL: managing active updates
- Islandoracon feedback
- How will objects-in-motion be handled
- Suggestion:
- Keep everything in OCFL (mutable head)
- Concern about complexity of having separate storage approaches
- Interest in Fedora6 transparency, rebuildability, preservation
- Complexity may not be worth it
- Noting, Fedora is optional in Islandora
- Implementation of a mutable-head
- It is possible... but maybe not as strong of consistency as other approaches
- Rebuildability and completeness is vital
- In-motion content is a new concept to the community
- Is there any issue with the notion of a mutable-head
- not really
- important that mutable-head be in the spec
- This could raise to the level of a Fedora governance question
- There is still importance in creating versions
- Even though this is a new concept to the community
- Complexity in Fedora's implementation is that some Fedora content will never be versioned
- Must be able to support rebuildability
- One solution is that un-versioned content will not be preserved
- This would not be a solution that is palatable with much of the existing Fedora community
- Is auto-versioning also a potential solution
- Is inventory/size bloat an issue?
- Counter-point: if users do not care about versioning, do they care about OCFL?
- Users still want the benefits of OCFL
- Users still want co-located content, if sometimes versioning is used
- ACTION: Andrew to bring mutable-head to OCFL spec editors
- Interest in alternate storage backends?
- For folks who do not care about OCFL qualities, other backends are possible
- Conversation at Islandoracon has come from Fedora birds-of-a-feather and hallway talk
Actions
- Aaron Birkland to look explore notion of OCFL client with database as authoritative metadata source + asynchronous writing of the inventory.json file
- David Wilcox will review the NDSA matrix and pull out the concrete technical requirements that could be considered during the Fedora 6 development.
