Versions Compared

Old Version 14

changes.mady.by.user Danny Bernstein

Saved on

compared with

New Version Current

changes.mady.by.user Peter Eichman

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  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 
    Jira
    serverDuraSpace JIRA
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
    keyFCREPO-1889
     when Jared Whiklo  is finished with the above.
  •  Peter Eichman : to review 
    Jira
    serverDuraSpace JIRA
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
    keyFCREPO-1889

...