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://duraspace.zoom.us/my/fedora 
  

  • Dial-in: 
    +1 408 638 0968
    +1 646 876 9923
    +1 669 900 6833
    Meeting ID:
    812 835 3771

• Join fedora-project.slack.com on the "tech" channel

Attendees

1. Andrew Woods 
2. Danny Bernstein
3.  Ben Pennell 
4. Jared Whiklo  
5. Aaron Birkland  
6. Bethany Seeger
7. Peter Eichman 
8. David Wilcox

Agenda

1. Announcements

   1. Fedora Leaders update
   2. LDP - OCFL Not-A-White paper 
2. Sprint Planning Update
3. Happy camel toolbox news

4. Import Export "mini-sprint"

5. For consideration: two-layer architectural approach - refactoring the persistence layer

6. <your discussion point here>

7. In Review

   Click here to expand...

   type	key	summary	assignee	reporter	priority	status	resolution	created	updated	due
   Unable to locate Jira server for this macro. It may be due to Application Link configuration.

8. Please squash a bug!

   Click here to expand...

   key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution
   Unable to locate Jira server for this macro. It may be due to Application Link configuration.

9. Tickets resolved this week:

   Click here to expand...

   key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution
   Unable to locate Jira server for this macro. It may be due to Application Link configuration.

10. Tickets created this week:

    Click here to expand...

    key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution
    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Minutes

1. Fedora Leaders Update:
   1. Document's purpose is to provide a clear description of how LDP and RDF fit into Fedora 5 and 6 respectively.
   2. 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.
2. 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.
3. LDP and RDF in Fedora document
   1. comes from Fedora leaders call
   2. questions the degree of influence that RDF has on Fedora architecture
   3. purpose of document is not to debate issues
   4. purpose IS to describe where RDF concepts fit in the Fedora architecture
   5. looking to come to a consensus about what is true
   6. use for guidance for Fedora 6 implementation
   7. hoping to clear up some basic misconceptions about impact of things like LDP
4. putting a halt on sprint planning until we get clarity and unity on Fedora 6 direction from leaders
5. camel toolbox
   1. many dependencies, were confusing
   2. message count expected was 2, now there are 3x messages due to versioning
   3. upgrading to Camel 2.20 would get rid of security alerts
   4. still failing on some seemingly basic tests
      1. 2.18.2 would resolve all but 1 moderate severity
   5. Travis is failing because of too many warnings from Jetty about Shiro
   6. upgrading Vagrant shouldn't be too hard
   7. 4.8.0 camel toolbox released
6. import-export "mini-sprint"
   1. Danny has started working on export of versions for Fedora 5
   2. looking for folks to join this work
   3. objective get import/export working for Fedora 5
   4. looking for volunteers for the next week, mostly to work on PRs
      1. Bethany will be available for some PR review
7. two-layer architectural approach
   1. good to see community to stating their needs
   2. there is an opportunity to try to satisfy the various camps
      1. current API, web standards-based, HTTP/LDP interaction
      2. folks that don't care about the HTTP layer, but DO care about repository and storage layer, transparent persistence, simple CRUD interaction
         1. API for this layer TBD
   3. architecturally we are already positioned for a two-layer approach
   4. what should an API at the bottom layer (persistence layer) look like?
      1. no LDP
      2. should a low-level API be HTTP?
      3. or native or CLI APIs?
   5. question of how much of the LDP relationships would get pushed into the persistence layer
   6. bottom layer as a stateful service
   7. support multiple simultaneous clients and be performant
      1. horizontally scalable persistence layer
      2. state-token-based locking
   8. is LDP the problem?
      1. if we can get a performant non-Modeshape version using LDP, we could improve the perception of LDP
   9. in Fedora 4, there was a perception that you MUST use RDF
   10. go back to a model that actively supports storing XML
       1. messaging, but also need more XML-based tooling to get people to accept storing XML into Fedora 6
       2. really looking at a model of Fedora 3 to Fedora 6
       3. the LDP aspect can more-or-less be ignored
   11. use a minimalist two-level hierarchy where the top level is an object, next level is datastream
   12. OCFL community meeting
       1. discussion about an HTTP API for OCFL
       2. if it is possible, can LDP can be overlaid over OCFL?
       3. OCFL subset-of LDP subset-of Fedora API
       4. try to make this pattern (basic CRUD interactions with a repository) known and accepted
       5. Fedora 3 mode that complies with Fedora 1.0 API but that can ignore the LDP stuff
       6. what would the ideal API for folks not interested in LDP
          1. folks want JSON
          2. better messaging around JSON-LD
          3. JSON merge patch for updates

• Peter Eichman  is planning to work on documenting UMD's fixity check system on the  Fedora in Production: Case Studies wiki page.
• Peter Eichman :  will complete review of  Unable to locate Jira server for this macro. It may be due to Application Link configuration.  when Jared Whiklo  is finished with the above.
• Peter Eichman : to review  Unable to locate Jira server for this macro. It may be due to Application Link configuration.