This meeting is a hybrid teleconference and slack chat. Anyone is welcome to join...here's the info:
- Andrew Woods
- Danny Bernstein
- Ben Pennell
- Jared Whiklo
- Aaron Birkland
- Bethany Seeger
- Peter Eichman
- David Wilcox
- Fedora Leaders update
- LDP - OCFL Not-A-White paper
- Sprint Planning Update
- Happy camel toolbox news
Import Export "mini-sprint"
- For consideration: two-layer architectural approach - refactoring the persistence layer
<your discussion point here>
Please squash a bug!
Tickets resolved this week:
Tickets created this week:
- Fedora Leaders Update:
- Document's purpose is to provide a clear description of how LDP and RDF fit into Fedora 5 and 6 respectively.
- Not a debate, but an attempt to describe so that we can all be on the same page when we talk about the future of Fedora.
- fcrepo-camel-toolbox build is failing on travis only due to excessive logic output due to a Shiro bug and one test is failing due to camel dependency update.
- LDP and RDF in Fedora document
- comes from Fedora leaders call
- questions the degree of influence that RDF has on Fedora architecture
- purpose of document is not to debate issues
- purpose IS to describe where RDF concepts fit in the Fedora architecture
- looking to come to a consensus about what is true
- use for guidance for Fedora 6 implementation
- hoping to clear up some basic misconceptions about impact of things like LDP
- putting a halt on sprint planning until we get clarity and unity on Fedora 6 direction from leaders
- camel toolbox
- many dependencies, were confusing
- message count expected was 2, now there are 3x messages due to versioning
- upgrading to Camel 2.20 would get rid of security alerts
- still failing on some seemingly basic tests
- 2.18.2 would resolve all but 1 moderate severity
- Travis is failing because of too many warnings from Jetty about Shiro
- upgrading Vagrant shouldn't be too hard
- 4.8.0 camel toolbox released
- import-export "mini-sprint"
- Danny has started working on export of versions for Fedora 5
- looking for folks to join this work
- objective get import/export working for Fedora 5
- looking for volunteers for the next week, mostly to work on PRs
- Bethany will be available for some PR review
- two-layer architectural approach
- good to see community to stating their needs
- there is an opportunity to try to satisfy the various camps
- current API, web standards-based, HTTP/LDP interaction
- folks that don't care about the HTTP layer, but DO care about repository and storage layer, transparent persistence, simple CRUD interaction
- API for this layer TBD
- architecturally we are already positioned for a two-layer approach
- what should an API at the bottom layer (persistence layer) look like?
- no LDP
- should a low-level API be HTTP?
- or native or CLI APIs?
- question of how much of the LDP relationships would get pushed into the persistence layer
- bottom layer as a stateful service
- support multiple simultaneous clients and be performant
- horizontally scalable persistence layer
- state-token-based locking
- is LDP the problem?
- if we can get a performant non-Modeshape version using LDP, we could improve the perception of LDP
- in Fedora 4, there was a perception that you MUST use RDF
- go back to a model that actively supports storing XML
- messaging, but also need more XML-based tooling to get people to accept storing XML into Fedora 6
- really looking at a model of Fedora 3 to Fedora 6
- the LDP aspect can more-or-less be ignored
- use a minimalist two-level hierarchy where the top level is an object, next level is datastream
- OCFL community meeting
- discussion about an HTTP API for OCFL
- if it is possible, can LDP can be overlaid over OCFL?
- OCFL subset-of LDP subset-of Fedora API
- try to make this pattern (basic CRUD interactions with a repository) known and accepted
- Fedora 3 mode that complies with Fedora 1.0 API but that can ignore the LDP stuff
- what would the ideal API for folks not interested in LDP
- folks want JSON
- better messaging around JSON-LD
- JSON merge patch for updates