...
...
- Feedback on removing fcr:fixity endpoint -
- community Community seems more interested in continuing to have fcr:fixity endpoint (at least in for short term). Has any one expressed interest in maintaining it long term.?
- Kevin Ford - provides 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 2nd second request by client to fetch the original checksum to do the comparison on the client side.
- Thought There was the thought that this type of checking should be inherent functionality to a digital preservation system. Every 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.
- 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 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.
- UMD really wants / uses this feature.
- 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.
- Is it the idea that Fedora 5 conform to the API spec and nothing more? The 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 Fedora 5 impl into an example or model piece of software, but if there are these it's missing useful features that are needed to be added (back in) to make it useful, a full fledge repository, the software may be come become less useful because as it won't be ready (as in meeting all the needs) fulfill basic preservation needs right "out of the box".
- If it's something the community wants, removing it may not make sense. We However, 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 fcr:fixity endpoint in front of fedora – 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 Fedora - so it's potentially still two requests to Fedora.
- Kevin Ford and others have concern about increased complexity being pushed to client - adding more work for them.
- 'want-digest' on a resource - what does it
- 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.
- 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.
- If the spec group finds a formal way to do it in Fedora 5 (via other docs), that would be preferred.
- Getting to 5.0
- Documentation
- External-content - still addressing missed comments that were not immediately shown showing up in github.
- (skipped)
- 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.
- Import / export: most of the end points are still the same, so things may work relatively well.
- Camel toolkit - activity streams changed, code can be refactored - Peter Eichman is interested/willing to work on this
- there is come code Aaron Coburn has that could be helpful here
- fcrepo-vagrant - shiro auth might cause tweak to setup? Jared Whiklo will look at
- 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?
- might be a good idea to keep the fcrepo-java-client - perhaps talk with Daniel Lamb or Michael Durbin and see what they think.
- Can someone take a look at this
so we can wrap it up?Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2604
...
- Look at fcr:fixity in JIRA - creating a ticket and look at options
- See if possible option to be a for fixity checking could be an API-X service
- Talk to API Spec group about returning fixity check result as an additional header, returned on 'want-digest'.
- Peter Eichman - How See how tightly bound our current implementation is to modeshape, in regards to the fixity endpoint. Can look at at the end of next week.
- Message to list-serve to see who might be using fcrepo-java-client outside of fcrepo-camel
...