Page History

...

1. Upcoming Sprint
   
   1. Emerging focus on WebAC.  
   2. Versioning will probably go through the whole two weeks
   3. Documentation will be needed:  
      1. Adopters Guide - can someone look at a pending PR and approve it?
      2. Document: Breaking Changes Between 4.7.x and 5.0.0 - created as a place to put differences
   4. Focus is mainly API alignment, but if there's time maybe have some folks working on fixing issues that are not specifically sprint related.
   5. Danny Bernstein has been doing some sprint planning which should be complete by Friday. If you know of an issue that he should consider as part of the sprint, let him know.  He will update the sprint alingment document and send an email on Thursday or Friday of this week. 
   6. Sprint Kickoff meeting is at 11 am ET on Monday morning.  Seems like that time works for most, if not all.  
2. Sprint Planning 
   1. Memento discussion - Ben Pennell talked about approach the group seems to be coalessing on. He is working on implementing that and hoping to have a PR this afternoon so people can see what this approach would look like.  He is having a few issues getting subjects correct right now.  Issue around etags and the wrong one being returned when asking for description (of a binary) - you currently get the etag of the binary.  Not sure why it was done this way, may have been a convenience thing.   Should we make it so you get the descriptions etag when you ask for it?  General thought is that the binary's description should return it's own etag - general concensus here.  Ben will work with this approach in his PR. We'll go down this road for now and reconsider if we learn more about why this behavior was created this way in the first place.
   2. LDP responses for mementos question talk about - headers persisted as part of the mementos?    consideration of etags
      1. The acl wouldn't be part of the memento, so not stored with them
      2. apply permissions to time map for creation / view / delete of memento
      3. as time goes along and permisions might get changed – you don't want the permission from 1 month ago to work with some of your mementos and others have different perms. Idea is that all the mementos fall into the same bucket – and the permission for that bucket, as a whole, is what might change. 
      4. ACL's for mementos - an alg could look at current resources ACL – that ACL  is what's applied to all memento resources.   Before you check the original resource, you check the time map first so that the mementos could have different perms.
         1. Peter Eichman - would have to duplicate ACLs? 
         2. mementos can only be read or deleted, so do they need a different ACL?  Can they follow whatever inheritance path structure we define? 
      5. feedback from leadership on deleting a resource - what does it mean for the versions?  leadership seems to like the idea of keeping the tombstone with versions still in place upon deleting of resource.  So the versions live under the tombstone. So one could recover.  Need to think about how to restore a version from a tombstone and maybe keep the same URL. Then what happens when you delete the fcr:tombstone – all mementos will get purged for that resource.
   3. WebACLs
      1. Assessment of removing WebACLs from Modeshape. Danny took a quick look and didn't think it'd be too complicated to separate the two.  Perhaps we can accomplish this during the sprint
      2. There is a no more then 1:1 resource:ACL, which ignores inheritance.  If an ACL triple is editiable by the user, then we can run into complications of change to that triple or adding more ACL triples.  
      3. What is the implication of dropping 5.4 from the spec? – Perhaps when you create a resource, it has a default location for that resources ACL, whether or not one is there.  
         1. Maybe we have a server managed location like fcr:acl  - that would be a starting point for locating the ACL, if nothing at fcr:acl, go up the inheritance tree from there to get the ACL. 
         2. Example from Peter Eichman:  top level PCDM container – all the PCDM modelled collections are all siblings under that.   There is an ACL on that parent container, so no resource in it has it's own ACL.  Per collection defaults for ACLs their current heirarchy won't work for themthemb because of data modeling.  AccessToClass impl would make that available to them. Creation of resources would need to add an appropriate access class to that.  
         3. Leads back to question of what is best practice for data modeling in Fedora 4.  .   At one point in time it seemed like the above scenario was a fairly performant way to model ones data. 

   
   

Actions

•  Danny Bernstein: to create list of breaking changes in Fedora5
•  Danny Bernstein: to send message to community wrt whether webac breaking change is tolerable in Fedora5 (or should continue to be supported, and deprecated)
•  Danny Bernstein: create JIRA ticket too look at recovering a resource from a tombstone version. 
•  Peter Eichman:  Do short write-up of ACL inheritance conundra. 
•  Danny Bernstein:  To reach out to SOLID folks with Peter Eichman's concerns