Page tree
Skip to end of metadata
Go to start of metadata

Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:

Attendees 

Agenda

  1. PUT with server-managed triples... fail or ignore?
    1. FCREPO-1928 - Getting issue details... STATUS
  2. 4.5.1 Release planning
    1. One blocker:  FCREPO-1933 - Getting issue details... STATUS
    2. Release Testing Procedures - Template
  3. Bugs are beginning to pile up

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution
    Loading...
    Refresh

  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

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution
    Loading...
    Refresh

Ticket Summaries

  1. Please squash a bug!

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution
    Loading...
    Refresh

  2. Tickets resolved this week:

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution
    Loading...
    Refresh

  3. Tickets created this week:

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution
    Loading...
    Refresh

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  FCREPO-1928 - Getting issue details... STATUS

  2. 4.5.1 Release planning - getting a release out would be beneficial
    1. one blocker -  FCREPO-1933 - Getting issue details... STATUS  - 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. FCREPO-1937 - Getting issue details... STATUS  - Aaron Coburn 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".