...
This meeting is a hybrid teleconference and IRC 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
- Or point your IRC client to #fcrepo on irc.freenode.net
Join fedora-project.slack.com on the "tech" channel
- Join the #fcrepo chat room via Freenode Web IRC (enter a unique nick)
Attendees
...
- Bethany Seeger
- Jared Whiklo
- Peter Eichman
- Yinlin Chen
- Esmé Cowles
- Doron Shalvi
- Kevin FordRandall Floyd
- Ben Pennell
- Aaron Birkland
- Joe Harrington
- James Silas Creel
- David Wilcox
Agenda
- Sign up for Sprint 2 on the API Alignment Sprint pagethe upcoming Alignment Sprint
- Review Ben Pennell's exposition of options for implementing mementos of binaries and their descriptions
- Documentation mini sprint
- Who is interested?
- Timeframe
- Objective
- Next steps
- Low hanging tickets that could be worked in a "pre"Pre-sprint" work that can be done
- Reading work?
- Low-hanging JIRA tickets:
- ?
- ?
- Shall we consider using Duraspace checkstyle rules?
- Checkstyle Analysis
- Repo
- There are three rules in the fedora checkstyle rules that are not in the Duraspace checkstyle rules:
- requiring @author in javadoc
- "final" required for parameter variables
- "final" required for local variables
Sprint tickets
| Jira | ||||||
|---|---|---|---|---|---|---|
|
...
Please squash a bug!
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 Tickets resolved this week:
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 Tickets created this week:
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
Minutes
- Welcome to new Fedora Committer: Peter Eichman
- Sign up for Sprint Alignment
- Alignment Sprint Retrospective
- Issues: https://jira.duraspace.org/issues/?filter=14401
- Danny: very productive sprint, lots of issues closed, major milestones
- memento functionality mostly implemented
- team very engaged, plus lots of contribution from Jared Whiklo even though he wasn't offically on the sprint
- Yinlin: one suggestion: would appreciate documentation for command-line usage for creating ACLs
- Randall: early in the sprint, some PRs got merged while I was still testing them — maybe we should signal what we are reviewing/testing?
- Danny: you can specify the reviewer on the PR or JIRA ticket (including self-assigning), which might help make it clearer who's reviewing what
- Ben: we can have multiple reviewers on PRs
- Danny: if you're not comfortable merging a PR, you can review/test and request a second pair of eyes
- Joe: asking on Slack before merging is another good way to make sure we're all on the same page
- Ben: a documentation mini-sprint before the next sprint might be good
- Major features and themes for next sprint
- DateTime negotiation
- ACL append, including possibly moving ACL enforcement out of Modeshape
- Moving ACLs out of the modeshape layer.
- https://fcrepo.github.io/fcrepo-specification/#append-ldprs
- 5.7.3 LDP-NR - Patching Binaries (LDP-NR) - do we plan to support - if so what should it look like?
- Ben: seems worth investigating, since it would be a better long-term approach
- Danny: Exactly, would make it easier to switch to a non-Modeshape backend
- Aaron: There's a mismatch between Mode and WebAC permission modes
- Ben: hard to do on a sprint, since a major refactor like that would block other work
- Peter: fine with deferring append support to 5.1 release, but want to make sure nobody is waiting for it
- Danny: we could work on the other tickets without duplicating effort with ACL append implementation
- Binary description mementos
Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2709 - Ben: with binary mementos, you have both the binary and the description, which would require two updates to modify them
- But mementos are supposed to be immutable, so how would you create the binary and the description?
- Do we want to make the binary and description mementos separate from each other to avoid this?
- Esmé: Could we do a three-step process:
- create binary memento (auto-creating description memento)
- delete binary description memento
- create desired binary description memento
- Ben: what would the state be after you deleted the description memento? It could fall back to the current state of the description
- Seems like it could work, but also seems like more requests than needed
- Danny: This seems it is effectively allowing the binary description to be modified
- Jared: Almost any way you do this would allow inconsistent state, unless you separate them
- Ben: My PR separates the binary and description mementos, so I think that's feasible, it's really just a matter of deciding how we want them to behave
- It would be good to have a wiki page documenting how we want this to work
- Feedback on Peter Eichman's writeup on the use of userAgent and groupAgent base URI's and their relationship to WebAC in order to clarify whether or not what if anything needs improvement/clarification/alignment
- Danny: looks good to me — other folks can comment on the document
- the upcoming Alignment Sprint
- Review Ben Pennell's exposition of options for implementing mementos of binaries and their descriptions
- Document has been shared on chat and listserv. Includes ideas from Esme and Ben. There have been many suggestions on different ways to create and retrieve binary mementos.
- What kind of link headers should be provided by Fedora? Should Fedora determine if a binary and description memento are related?
- Three possible implementations noted:
- Create mementos one by one. Two requests would be needed.
- Similar to 1. above, except on retrieval Fedora would provide a "described by" link to the original resource instead of attempting negotiation.
- A single request would create both a binary and description memento, when importing a historical memento. The description memento would then effectively be a newly created node.
- Historical mementos are primarily for importing from another Fedora, but could also be used to create additional versions from scratch.
- Bethany prefers an approach where a single post creates both. Jared prefers the second approach because it alleviates the server from having to handle negotiation.
- The group has previously agreed to replace references between resources with literals. Should we handle headers the same way?
- Possibly, we are stretching the Memento spec. When requesting a Memento object, how sould we respond in order to still be compliant with LDP?
- Deletions
- If the canonical object is deleted, the versions are also deleted. Perhaps split binaries and descriptions into seaprate objects? Seems not worthwhile.
- Should Fedora keep versions of items that have been deleted, so that these could be restored? Memento is capable of doing so if we desire. Makes sense in a Disaster Recovery scenario. To do so, we'd have to move the timemaps out into a separate location in the repo.
- Conceptually, is versioning for items only currently in the repo, or all items that have ever been in repo?
- Outstanding questions:
- Should we have LDP responses for mementos?Does a memento object act as a full LDP object, particularly with respect to headers?
- Are the edge things (such as headers) important for our users' workflows? Should we handle these?
- Is versioning for items only currently in the repo, or all items that have ever been in repo?
- Should Fedora keep versions of items that have been deleted?
- Documentation mini sprint
- Issues with documentation on the wiki were noted. Is the documentation correct and sufficient?
- To be discussed in the tech call next week.
- "Pre-sprint" work that can be done
- It would be helpful to finish work from the last sprint - creating mementos of resources - before the next sprint begins, to avoid questions and merge conflicts in next sprint. This work is defined in an existing ticket describing the creation of binary mementos. To aid this process, it would be helpful to make decisions on binary mementos now.
- The next sprint will focus on mementos and ACLs.
Peter promised an investigation into moving WebAC from ModeShape to the web layer.
- The WebAC tickets fall into a few categories:
- Fixing headers, aligning with WebAC spec.
- Dealing with ACL append mode. Tricky / impossible to do at Modeshape layer.
- Implementing support for default ACLs. Separate from ACL append issues?
- Regarding binary versions, we could use input from the community and Fedora leaders before the next Sprint. Jared will send an email to Fedora leaders to get input. David recommends presenting a summary in the email including use cases and benefits, with technical details attached. Fedora leaders will include input from the Islandora and Samvera communities.
- Also worthwhile to obtain feedback from Fedora leaders on the deletion issue (true deletes or keep a copy to be restored), since this is a broad issue regarding expectations of a repository.
- All of the above should be discussed at the next sprint planning meeting.
- Duraspace checkstyle rules - Danny to bring up next week.James: Texas A&M has been looking at a lot of different platforms, including Hydra/Islandora, existing DSpaceGenerating IIIF manifests, Spotlight exhibits, going into production very soon
- Actions
- Yinlin Chen: Review and update ACL creation documentation: Quick Start with WebAC
- Ben Pennell: Create a wiki page documenting options for mementos of binaries and their descriptions