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. Updates and Announcements
    1. Fedora 4.6.0 has been released!
    2. Registration is open for Fedora Camp NYC November 28-30
    3. Archivematica Camp - updates? outcomes?
    4. Import/Export sprint update
  2. Linked Data Notifications - roll into Fedora as an fcrepo-exts project?
  3. GraphQL - roll into Fedora as an fcrepo-exts project?
  4. Process for deprecating fcrepo-transform
  5. concurrency
  6. Revisit default behavior on PUT requests containing RDF bodies:  FCREPO-1928 - Getting issue details... STATUS
  7. Fedora 4.7.0 planning
    1. Depends on community verification of /fcr:backup and /fcr:restore
  8. Status of "in-flight" tickets

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

Ticket Summaries

  1. Please squash a bug!

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

  2. Tickets resolved this week:

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

  3. Tickets created this week:

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

Minutes

  1. Updates and Announcements
    1. Fedora 4.6.0 has been released!
      1. Last release that will be dependent on ModeShape 4.  Master branch is now dependent on ModeShape 5 and is expected to be the basis for release 4.7.
      2. Release Notes will be updated to call out changes that necessitated a new major release (i.e., 4.6 instead of 4.5.2).
      3. There is now a mandatory database config item.  4.6.0 no longer defaults to LevelDB.
    2. Registration is open for Fedora Camp NYC November 28-30
    3. Archivematica Camp - updates? outcomes?
      1. Not much outcome in terms of Fedora - Archivematica hacking
    4. Import/Export sprint update
      1. Sprint began on Monday.  Goal is to complete Phase 1 priorities.
      2. So far, sprint is basically through Phase 1 a, b, and c sub-priorities
  2. Linked Data Notifications - roll into Fedora as an fcrepo-exts project? Unknown User (acoburn)
    1. Web resources can be linked to an inbox.  Clients can then create events on that inbox.
    2. Some minor contradictions between Fedora and the Linked Data Notifications spec – e.g., in the absence of an Accept header, Fedora will return Turtle and Linked Data Notifications spec calls for JSON-LD in that case.
    3. Is this worth including as an fcrepo-exts project?
      1. Examples of what it would be used for?  Dropping in notices about resource changes and specific out-of-band events associated with a resource; e.g., photo of college president gets used in a publication.
      2. Would existing audit functionality allow handling these kinds of events?  Currently, no clear way to get from a resource to the audit events associated with that resource (though there is to go from the audit event to the resource).
      3. Linked Data Notifications has the advantage of having a spec behind it.  We would not be making up our own thing.
      4. Adding this to fcrepo-exts seems to pose no conflict with the intent of fcrepo-exts (a place for interesting functionality related to Fedora that isn't core).
    4. Unknown User (acoburn) will work on this, though it may be a while before he gets to it.
  3. GraphQL - roll into Fedora as an fcrepo-exts project? Unknown User (acoburn)
    1. Most of Fedora deals with a resource as a whole.
    2. GraphQL is a draft spec for querying REST endpoints and returning only requested data.
    3. Unknown User (acoburn) will likely experiment with it locally at Amherst and later move it to a fcrepo namespace if it looks like it may be of wider use.
  4. Process for deprecating fcrepo-transform Andrew Woods
    1. 4.6.0 still has fcrepo-transform as part of webapp-plus.  Work has been done to pull the functionality into a Camel component.
    2. 4.6.0 returns a deprecation warning header.  The plan is to remove it from 4.7 and provide documentation on how to use the new Camel component functionality as a replacement.
    3. Anything else we should do to inform the community about this particular deprecation (or deprecations in general)?  No additional suggestions.
  5. concurrency
    1. Closely spaced PUT's to the same named resource can result in resources with same name, except for array type suffix.
    2. Michael Durbin is working on PR that involves locking.
    3. How aggressively do we want to lock or do we want to lock at all?
    4. Opinions
      1. What Michael Durbin is doing seems to address the issue.
      2. Any counter-arguments? A. Soroka (not on call) may have some?
      3. Short-comings of current solution
        1. Pairtree nodes need to be locked.  Michael Durbin will incorporate this.
        2. Doesn't work with transactions.  Note this for now and decide later whether to address.
      4. Would proposed approach potentially result in long-blocked requests if putting to same part of pairtree as a large binary PUT?  Michael Durbin will see how hard it would be to address this concern.
    5. Consensus is to move forward with proposed approach.
    6. Longshou Situ is also working on this at the ModeShape level: https://issues.jboss.org/browse/MODE-2624.
  6. Revisit default behavior on PUT requests containing RDF bodies:  FCREPO-1928 - Getting issue details... STATUS
    1. Change default behavior of PUT request.  Postpone to next call.
    2. To consider in the meantime:
      1. How does proposed change align with LDP specs?
      2. Is the proposed change the desired behavior?
      3. How does the http requirement for idempotency factor in?
  7. Fedora 4.7.0 planning – Postponed to next call.
  • No labels

1 Comment

  1. Regrets, I will miss this call.

    As regards item 6, I agree with Stefano that 4.2.4.1 explicly allows servers to ignore server managed properties.

    Requests with server managed properties could be handled as usual, emitting Conflict if a change is attempted. The downside I see to ignoring omission is that an attempt to delete in a PUT could silently fail. I.e. the request succeeds, but does not change the property. Given the assumption of minimal client knowledge of server implementation, the client would not know that the property is controlled by the server. A mitigating factor is that the server would insist that the property remain unchanged, anyway.

    A well behaved, general purpose client wouldn't rely on this kind of behavior, but with the above caveat, I don't see other harm in adopting it server side.