...
- Time: 11:00am Eastern Daylight Time US (UTC-4)
- Dial-in Number: (712) 775-7035
- Participant Code: 479307#
- International numbers: Conference Call Information
- Web Access: https://www.freeconferencecallhd.com/wp-content/themes/responsive/flashphone/flash-phone.php
- IRC:
- Join the #fcrepo chat room via Freenode Web IRC (enter a unique nick)
- Or point your IRC client to #fcrepo on irc.freenode.net
Attendees
- A. Soroka
- Yinlin Chen
- Esme Cowles
- Jared Whiklo
- David WilcoxBethany Seeger
- James R. Griffin III
- Benjamin Armintor
- Doron Shalvi
- Andrew Woods
- Allen Flynn
- Namita BahulekarKevin S. Clarke
- Unknown User (bbpennelacoburn)
- Diego Pino Navarro
- Bethany Seeger
- Andrew Woods
- Stefano Cossu
Agenda
- PUT with server-managed triples... fail or ignore?
Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1928
- 4.5.1 Release planning
- One blocker:
Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1933 - Release Testing Procedures - Template
- One blocker:
Bugs are beginning to pile up
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 30 jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 - Fedora Specification updates
- Messaging SPI
- Atomic Batch Operations - name? BatchOps? Bag-o'-Ops? OpSack? AtomicOp?
- CRUD
- Resource Versioning
- Binary Fixity Checking
- Authorization
- Updates on release status of fcrepo-camel and toolbox?
- ...
Status of "in-flight" tickets
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 2040 jqlQuery filter=13202 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
...
Please squash a bug!
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 2040 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 2040 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 2040 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
Minutes
- PUT with server-managed triples... fail or ignore?
- when you have a resource that you want to update with a PUT request (body being RDF, that doesn't not include server managed triples) the current logic tries to remove the triples that are not in the body of the RDF - throwing a 4XX error. Question - should we not require the server managed triples be included in the body of RDF request? Use case is to update the resource w/o having to know the server managed triples, since we can't change them anyways.
- Esmé Cowles reminded us that there is a
Prefer
header ```handling=lenient;return="minimal"``` that should do the trick. - Why is the default behavior taking server managed triples into consideration in the first place? Should it be the other way around? Lenient default - and have a strict option? Use case: one may want the full graph in a case where other's are editing at the same time - for conflicts.
- Esmé Cowles has used this recently - would be surprised if not implemented, since it's worked for him.
- Esmé Cowles will test this (the lenient and return=minimal)
- Confirms that PUT with return=minimal does do the requested behavior - updates the user triples.
- Esmé Cowles to update the documentation for this
- Should work for Stefano's use case.
- Andrew Woods - Is there any situation that should require putting the server managed triples back on the server? Would this capability help in some way? ETags should serve the same purpose.
- Concern about what it means if someone tries to write server manage triples that are wrong? Persist anyways?
- if you're trying to change the value on a server managed triple, you should get an exception. (including implicit removal for triple not specified in request).
- LDP spec says HTTP PATCH is for merge of data, and to use HTTP PUT for replacement.
- HTTP PUT for replacement - but with server managed triples it's more complicated.
- The delete and recreate use case is the one to figure out how to work with here.
- Want to be careful of situations with server managed triples that change w/o user knowing (Indirect Containers, for example).
- Two ways to do this stuff
- PUT with return=minimal
- SPARQL update via PATCH
- is it worth someone's time to investigate a different behavior here, or are things good as is?
- handling=strict; return="minimal" seems to give same response, which would probably be a bug.
- Benjamin Armintor - to add comments to
Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1928
- 4.5.1 Release planning - getting a release out would be beneficial
- one blocker -
- auth is a core feature and if not working, we can't really release.Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1933 - what do we think the expected behavior should be in this situation (a batch operation)?
- a link to an ACL that is prefixed with transaction context ?
- a link to an ACL that is not prefixed with transaction context?
- a link to an ACL that points to non-accessible uri?
- no ACL link header?
- behavior different depending on whether or not the ACL is created w/i the batch request?
- what do we think the expected behavior should be in this situation (a batch operation)?
- Any other tickets in before we put out release? None put forward
- Who can work on release?
- Benjamin Armintor - Release Manager
- Esmé Cowles and Jared Whiklo happy to help out
- one blocker -
- Bugs are beginning to pile up
- Unknown User (acoburn) willing to help sort this out. Context: whenever a successful change happens to a resource in fedora, an event is emitted for that resource. However, with MOVE, you can make changes on many resources, so we need to be able to fire off an event for each resource that changes as a result of that action. Easiest way to do this may be to say that there's a delete event and a create event for each contained resource.Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1937 - maybe emit a message ...
- delete events must recursively traverse tree.
- do we create the messages manually,or take advantage of what modeshape gives us? Later accomplished by not using modeshape move - but using modeshape creation and delete methods, resulting in messages. However could end up in inconsistent state.
- perform MOVE and then async send out delete and create messages
- Please review bugs and help on some of the major ones.
- Please continue working on the Fedora Specifications. If you're looking for feedback, please move the JIRA ticket related to your doc to "in review".