Versions Compared

Old Version 7

changes.mady.by.user Peter Eichman

Saved on

compared with

New Version 8

changes.mady.by.user Ben Pennell

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Time/Place

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

Attendees

Agenda

  1. Sprint Update
    1. Board
    2. Backlog
    3. List View of All Unclosed
  2. Update on  Ben Pennell's ongoing work on mementos of binaries and their descriptions.
    1. Proposed structure for all binaries
  3. Jira
    serverDuraSpace JIRA
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
    keyFCREPO-2604
    : 
    1. Are we comfortable with messages emitted?
  4. Jira
    serverDuraSpace JIRA
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
    keyFCREPO-2756
    , are there any  locations/paths that are designated to hold those ACLs created
  5. Jira
    serverDuraSpace JIRA
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
    keyFCREPO-2769
  6. Jira
    serverDuraSpace JIRA
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
    keyFCREPO-2753
    1. architecture question raised on Slack: http-api and auth-webac dependencies
  7. Planning for the Transition:  Two Fledgeling Efforts in need of volunteers.

    1. Adopters Guide

    2.  Breaking Changes Between Fedora 4.7.x and 5.0.0
  8. Supporting COAR Next Generation Repositories recommended technologies in Fedora
    1. Signposting
    2. ResourceSync
    3. others?
  9. Shall we consider using Duraspace checkstyle rules?
    1. Checkstyle Analysis
    2. Repo
    3. There are three rules in the fedora checkstyle rules that are not in the Duraspace checkstyle rules: 
      1. requiring @author in javadoc
      2. "final" required for parameter variables
      3. "final" required for local variables
    4. There are 40-odd lines in fcrepo4  that would need to be corrected to roll this out

Ticket Summaries

  1. Please squash a bug!

    Expand

    Jira
    serverDuraSpace JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    maximumIssues20
    jqlQueryfilter=13122
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


  2. Tickets resolved this week:

    Expand

    Jira
    serverDuraSpace JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    maximumIssues20
    jqlQueryfilter=13111
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


  3. Tickets created this week:

    Expand

    Jira
    serverDuraSpace JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    maximumIssues20
    jqlQueryfilter=13029
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


Minutes

...

  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.  

...

  1. COAR some recommendations for behaviours or technologies for next generation repositories.
    1. A list of things that Fedora already does, but some to consider as an addition or plugin. Some may have been considered.
    2. Signposting - a set of HTTP Headers to allow machine readable data to be added as headers.
    3. Has there been any discussion or consideration of these technologies for use before David takes it to the leaders.
    4. Its likely we will see a push for some of this type of stuff from a strategic level, there was a meeting of this group at CNI. Some members of the group said they might be able to get some funding for this.
    5. Please review the list and have some idea of whether we think it is applicable at the Fedora level or API-X level.
    6. There has been previous discussion of Linked Data Notifications which could be one option.
    7. Activity Streams Paging model might be a way to deal with the many members problem.
  2. Couple of documentation efforts that are underway. Not sure if we will get to them on the current sprint, but if you are not on the sprint and would like to help out with one of these efforts. Please reach out to Danny (email/slack) and he'll help you get started.
    1. Adopters guide is around the API transition from Fedora 4.7 to Fedora 5.0
    2. Breaking changes is around the Modeshape implementation.


  •  
  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 themb 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