You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

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. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  2. 4.5.1 Release planning
    1. One blocker:  Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    2. Release Testing Procedures

  3. Bugs are beginning to pile up

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  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

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Ticket Summaries

  1. Please squash a bug!

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  2. Tickets resolved this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  3. Tickets created this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

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 - 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 preferred header ```handling=lenient;received="minimal"``` 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 received=minimal) 
      1. Confirms that PUT with received=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 received=minimal
      2. SPARQL update via PATCH
    9. is it worth someone times to investigate a different behavior here, or are things good as is?
    10. handling=strict; received="minimal" may give same response, which would probably be a bug.   
    11. Benjamin Armintor - to add comments to  Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  2. 4.5.1 Release planning - getting a release out would be beneficial
    1. one blocker -  Unable to locate Jira server for this macro. It may be due to Application Link configuration.  - 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
  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.