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
Attendee
Agenda
- Feedback on /fcr:fixity endpoint
- Getting to 5.0
- Review of work that happened this week:
- 6 PRs merged
- Documentation: Kevin Ford has kicked it off.
- External content (proxy, copy, and redirect)
- 5.x Documentation Effort
- 5.x Documentation Updates matrix
- Another sprint?
- Timeframe/Duration/Availability
- Ecosystem tools dependent on the release:
- import export tool
- camel tool kit
- fcrepo4-vagrant
- java client
- api-x
- Review of work that happened this week:
Are we comfortable with messages emitted?
:
Ticket Summaries
Please squash a bug!
Tickets resolved this week:
Tickets created this week:
Minutes
- Feedback on removing fcr:fixity endpoint -
- community seems more interested in continuing to have fcr:fixity endpoint (at least in short term). Has any one expressed maintaining it long term.
- Kevin Ford - provides 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 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 for 'want-digest' and then 2nd request by client to fetch the original checksum to do the comparison on the client side.
- Thought that this type of checking should be inherent functionality to a digital preservation system. Every user will have to add something their system to do this checking or create their own way to do this work.
- 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.
- One thought – keep this in the Fedora 5 modeshape impl, or make sure that this 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.
- UMD really wants / uses this feature.
- Original thought was to move extraneous stuff which is not part of the Fedora API out of the modeshape impl.
- 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.
- There's a danger of pushing the modeshape fedora 5 impl into an example or model, but if there are these useful features that are needed to be added (back in) to make it useful, full fledge repository, the software may be come less useful because it won't be ready (as in meeting all the needs) "out of the box".
- If it's something the community wants, removing it may not make sense. We need to make sure it's maintainable long term. It's sounding like deprecation might be not be the way to go?
- 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.
- An extension (or plug-in, or side car) tool could be written in whatever language and shared across the community.
- Is there a ticket for deprecating fcr:fixity? Action item below
- API-X endpoint in front of fedora – is that an okay option? (providing that it's not a performance impact).
- Kevin Ford - concerns about duplicating traffic. Still need 'want-digest' and a comparison value from fedora - so it's potentially two requests to Fedora.
- Kevin Ford and others have concern about increased complexity pushed to client - adding more work for them.
- 'want-digest' on a resource - what does it
- GET on metadata for 'want-digest' to get the binary's info... not really semantically correct.
- What do people expect of a repository?
- 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).
- That sounds like a good option which would simplify the service.
- Might be a discussion for the API specification folks to talk about as well.
Actions
- Look at fcr:fixity in JIRA creating a ticket and look at options
- Peter Eichman - How tightly bound our current implementation is to modeshape, in regards to the fixity endpoint. Can look at at the end of next week.