Time/Place
This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:
- Time: 11:00am Eastern Daylight Time US (UTC-4)
- Dial-in Number: (712) 775-7035
- IRC:
Attendees
Agenda
- API Specification
- Based on community input 4.7.3 is reasonable
- Need upgrade utility:
- Suggestions from recent Fedora Leaders meetings
- Have an elected Fedora Committer join Fedora Leaders calls
- Have DuraSpace-hosted release testing infrastructure
- Interest in tighter alignment of effort and priorities between Islandora/Hydra/Fedora
- Upcoming meetings
- 2017-06-12 Performance - Scale meeting
- 2017-04-27 - Import - Export Planning Meeting
- ...
Status of "in-flight" tickets
Ticket Summaries
Please squash a bug!
Tickets resolved this week:
Tickets created this week:
Minutes
API Specification
- Andrew: Recently, there have been some challenges to the completion of the first working draft of the specification as a result of differing opinions about the goals of the effort among those working on the draft.
- Andrew: It seems clear that there is a continuum of opinions about what the purpose should be.
- The following document put together by Simeon Warner served as a guide for much of the discussion that ensued: https://wiki.duraspace.org/display/FF/2017-04-20+-+Fedora+Tech+Meeting?preview=/83237409/83237410/2017-04_fedora_dependencies.pdf
- Andrew: It seems clear that testability is an important characteristic that we are striving for in the specification.
- Andrew: The idea of having an "other behaviors" document (reflecting choices made by community implementation, but not required by the core) seems inevitable in order to document the community implementation.
- Esmé (responding to a question about Derby, which appears on the above document): Derby is a pure Ruby LDP implementation primarily used for testing in Hydra development.
- Esmé: I hope that the list of items in "other behaviors" box (examples include slug use and URI patterns) would shrink over time.
- Esmé: But would the community implementation ever move away from its Single Subject Requirement? That is perhaps doubtful, but other implementations might choose not to require this.
- Esmé: Having space for both innovation and evolution in the spec is OK.
- Esmé: Batch Atomic lends itself to being broken out as a separate document, but Fixity might not be so easy or appropriate to break out.
- Aaron C.: The origin of the discussion of fixity was around the use of HTTP Expect headers. [Secretary's note: There seemed to be general agreement that this use of expect headers was correctly removed from the specification since it was in conflict with the latest version of an underlying specification].
- Jared: Achieving swappability may well require work on the part of those making the swap (it's not just a matter of firing up the new implementation and done).
- Jared: Lack of DELETE in the spec is another example where swappability is complicated. Some implementations may allow it, but it is not guaranteed that all will, so clients that support that feature will not achieve swappability.
- Aaron C.: There is a lot of room for interpretation in any specification, and there are inevitably going to be cases where this leads to differences.
- Aaron C.: The more you limit your Fedora-specific assumptions, the more you'll be able to rely upon clients and tools created for the underlying specifications.
- Jared: Tying down to common specifications is good, but without forcing positions on some of the more questionable features. Realistically, a user is going to switch implementations only when there's a very good reason (when the alternative is clearly superior for a particular use case).
- Aaron C.: The reason for an alternative implementation is the ability to make different choices about things that are left open in the underlying specifications.
- Esmé: But even short of pure swappability, the specification could have the effect of easing the transition between implementations. Making multiple implementations available is also a good thing. But alternate implementations are not exclusively for the purpose of making different choices – having the specification will also make it possible to create what are in effect clones that make the same choices. One clone could show itself to be a superior implementation of the same set of features, even while making all the same choices on issues left open by the underlying specifications (the community implementation and Cavendish will likely be very close in this way).
- Jared: More specificity will also make it easier for clients to maneuver around changes as they come in the future.
- Nick: Most of what Fedora does is LDP. If swappability is a goal, then Fedora needs to take a stance on whether Single Subject is required (LDP is silent on this).
- Andrew: We need to move out of stalemate mode and go forward. Perhaps a call specifically for discussion of the spec with a process for resolving differences of opinion would allow us to take it forward. This group could also hash out the "other" behaviors document.
- Josh: We have needs and plans regarding completion of the WebAC implementation that are going to be difficult in the Modeshape version and which are held up by the lack of resolution on the API specification.
- Aaron C.: Perhaps a way forward would be to limit the number of editors, but with lots of contributors (this limits the number of folks who need to come to consensus, and is a model commonly used in other specifications in the wider community).
- Andrew: We didn't get to any of the other agenda items besides the API specification effort, but it is an important topic and this was a productive discussion.
