Time/Place

This meeting is a hybrid teleconference and slack chat. Anyone is welcome to join...here's the info:

Attendee

Agenda


  1. Feedback on /fcr:fixity  endpoint
  2. Getting to 5.0 
    1. Review of work that happened this week: 
      1. 6 PRs merged
      2. Documentation:  Kevin Ford has kicked it off. 
      3. External content (proxy, copy, and redirect) 
    2. 5.x Documentation Effort
      1. 5.x Documentation Updates matrix
    3. Another sprint? 
      1. Timeframe/Duration/Availability
    4. Ecosystem tools dependent on the release:
      1. import export tool
      2. camel tool kit  
      3. fcrepo4-vagrant
      4. java client 
      5. api-x 

    1. Are we comfortable with messages emitted?

Ticket Summaries

  1. Please squash a bug!


  2. Tickets resolved this week:


  3. Tickets created this week:


Minutes

  1. Feedback on removing fcr:fixity endpoint  -   
    1. Community seems interested in continuing to have fcr:fixity endpoint (at least for short term).   Has any one expressed interest in maintaining it long term? 
    2. Kevin Ford - fcr:fixity is an endpoint you can functionally replace, but it's not a one to one swap.   In fedora 5 it can be done but it's been pushed off to the client to do the work.  'want-digest' provides digest, but client still needs to compare to a previously stored digest. 'fcr:fixity' as it exists today has the repo do that work. This change would increase traffic to fedora 5: first for 'want-digest' and then second request by client to fetch the original checksum to do the comparison on the client side.  
    3. There was the thought that this type of checking should be inherent functionality to a digital preservation system. Removing this means that every user will have to add something their system to do this checking or create their own way to do this work.  
    4. Unless client is storing their own older fixity information, there are more calls to server.  Not easy to do if you have tens of thousands of resources to check on a regular basis. 
    5. One thought – keep this in the Fedora 5 modeshape impl, or make sure that there is a well supported community tool or add-on.  Something easy for users of Fedora 5 to add on to system w/o a lot of work. 
    6. UMD really wants / uses this feature. 
    7. Why remove fcr:fixity in the first place?  Original thought was to move extraneous stuff which is not part of the Fedora API specification out of the modeshape impl. 
    8. Is it the idea that Fedora 5 conform to the API spec and nothing more?  The goal was to keep it a small, easy to maintain version of software that conforms to the specification.   Supporting the spec as it is right now.  
    9. There's a danger of pushing the modeshape Fedora 5 impl into an example or model piece of software, but if it's missing useful features that are needed to be a full fledge repository, the software may become less useful as it won't fulfill basic preservation needs right "out of the box".
    10. If it's something the community wants, removing it may not make sense. However, we need to make sure it's maintainable long term.   It's sounding like deprecation might be not be the way to go? 
    11. For UMD - an API-X option would be useful, or a compiled in extension (like audit module).  Not in core, but a module you can add in. 
    12. An extension (or plug-in, or side car) tool could be written in whatever language and shared across the community. 
    13. Is there a ticket for deprecating fcr:fixity?  Action item below
    14. API-X fcr:fixity endpoint in front of Fedora – is that an okay option?   (providing that it's not a performance impact)
      1. Kevin Ford - concerns about duplicating traffic.   Still need 'want-digest' and a comparison value from Fedora - so it's potentially still two requests to Fedora.  
      2. Kevin Ford and others have concern about increased complexity being pushed to client - adding more work for them.  
    15. There was discussion about asking the description (fcr:metadata) resource for a binary object about the fixity for the binary. GET on metadata for 'want-digest' to get the binary's info... not really semantically correct.
    16. What do people expect of a repository?
    17. Maybe fixity could be at the HTTP layer?  Maybe it could be returned in a header - so you get the same functionality just a different way (like a fixity status returned). 
      1. That sounds like a good option which would simplify the service. 
      2. Might be a discussion for the API specification folks to talk about as well. 
        1. If the spec group finds a formal way to do it in Fedora 5 (via other docs), that would be preferred.  
  2. Getting to 5.0
    1. Documentation
    2. External-content - still addressing missed comments that were not immediately showing up in github.
    3. (skipped)
    4. Ecosystem tools – ensure that all of these still work when 5.0 is released.  Determining what, if any, changes need to be made to them. 
      1. Import / export:  most of the end points are still the same, so things may work relatively well.  
      2. Camel toolkit - activity streams changed, code can be refactored - Peter Eichman is interested/willing to work on this
        1. there is come code Aaron Coburn has that could be helpful here
      3. fcrepo-vagrant - shiro auth might cause tweak to setup? Jared Whiklo will look at
      4. fcrepo-java-client - who uses this?  Java client that helps you interact with fedora from your app.  Looks like fcrepo-camel uses it.  Who might use this outside of fcrepo-camel? Can fcrepo-java-client be a reference client impl for the API spec?
        1. might be a good idea to keep the fcrepo-java-client - perhaps talk with Daniel Lamb or Michael Durbin and see what they think. 
  3. Can someone take a look at this   so we can wrap it up?