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
  • 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
• Esme Cowles 
• Jared Whiklo 
• Bethany Seeger  
• Benjamin Armintor
• Andrew Woods
• Allen Flynn
• Namita Bahulekar
• Unknown User (acoburn)
• Stefano Cossu

Agenda

1. PUT with server-managed triples... fail or ignore?
   1. 
2. 4.5.1 Release planning
   1. One blocker: 
   2. Release Testing Procedures - Template

3. Bugs are beginning to pile up

4. Fedora Specification updates
   
   1. Messaging SPI
   2. Atomic Batch Operations - name? BatchOps? Bag-o'-Ops? OpSack? AtomicOp?
   3. CRUD
   4. Resource Versioning
   5. Binary Fixity Checking
   6. Authorization
5. Updates on release status of fcrepo-camel and toolbox?
6. ...

7. Status of "in-flight" tickets

Ticket Summaries

1. Please squash a bug!

2. Tickets resolved this week:

3. Tickets created this week:

Minutes

1.  PUT with server-managed triples... fail or ignore?
   1. 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.
   2. Esmé Cowles reminded us that there is a Prefer header ```handling=lenient;return="minimal"``` that should do the trick.
   3. 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. 
   4. Esmé Cowles has used this recently - would be surprised if not implemented, since it's worked for him.  
   5. Esmé Cowles will test this (the lenient and return=minimal) 
      
      1. Confirms that PUT with return=minimal does do the requested behavior - updates the user triples. 
      2. Esmé Cowles to update the documentation for this 
      3. Should work for Stefano's use case. 
   6. 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.
   7. Concern about what it means if someone tries to write server manage triples that are wrong?  Persist anyways?  
      1. 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). 
      2. LDP spec says HTTP PATCH is for merge of data, and to use HTTP PUT for replacement.
      3. HTTP PUT for replacement - but with server managed triples it's more complicated.
      4. The delete and recreate use case is the one to figure out how to work with here.  
      5. Want to be careful of situations with server managed triples that change w/o user knowing (Indirect Containers, for example). 
   8. Two ways to do this stuff
      1. PUT with return=minimal
      2. SPARQL update via PATCH
   9. is it worth someone's time to investigate a different behavior here, or are things good as is?
   10. handling=strict; return="minimal" seems to give same response, which would probably be a bug.   
   11. Benjamin Armintor - to add comments to 
       
       
2. 4.5.1 Release planning - getting a release out would be beneficial
   1. one blocker -  - auth is a core feature and if not working, we can't really release.  
      1. what do we think the expected behavior should be in this situation (a batch operation)?
         1. a link to an ACL that is prefixed with transaction context ?
         2. a link to an ACL that is not prefixed with transaction context?
         3. a link to an ACL that points to non-accessible uri?
         4. no ACL link header?
         5. behavior different depending on whether or not the ACL is created w/i the batch request?
   2. Any other tickets in before we put out release?  None put forward
   3. Who can work on release?  
      1. Benjamin Armintor - Release Manager
      2. Esmé Cowles and Jared Whiklo  happy to help out
3. Bugs are beginning to pile up
   1.  - 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. 
      1. maybe emit a message ...
      2. delete events must recursively traverse tree. 
      3. 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.
      4. perform MOVE and then async send out delete and create messages
   2. Please review bugs and help on some of the major ones. 
4. 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".