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

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

Compare with Current View Page History

Version 1 Next »


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



  1. Outstanding issues on Fedora API Specification

    1. Remove atomic operation section?
    2. The Columbia requirements for "external content"
  2. ...
  3. Status of "in-flight" tickets

      Click here to expand...

Ticket Summaries

  1. Please squash a bug!

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution

  2. Tickets resolved this week:

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution

  3. Tickets created this week:

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution


  1. Outstanding issues from API

    1. Atomic operations came up at DC Fedora user group. Maryland makes extensive use of Atomic operations, David Wilcox mentioned we might remove it and that in that discussion there was no strong voice opposing that viewpoint. Esmé Cowles wanted to mention that some people do have a strong use case for atomic operations as they are not here today.
      1. Removing it, means removing it from the core specification and not that it couldn't be an optional feature.
      2. What do you consider the purpose of the specification to be?
        1. some people feel like the spec serves the purpose of firm guidance of features if they are implemented. Not saying they have to implement them and others say whether they must exist.
        2. others see spec as a concrete minimal definition to define what it is to "be Fedora", very concrete/testable, strong guidance
        3. guidelines for swapability and interoperability, I could conceptually swap implementations out under the covers and the front end would not care so long as they both implement the specification.
      3. Unknown User (acoburn) - what the required behaviours of a Fedora implementation would have, because if you know what those are it is easier to swap out the backend tools/libraries/etc. 
      4. If you have multiple clients working on separated parts of the repository, that is easy to handle. But when you have multiple clients working on the same resource and have overlap. Then you need to interweave multiple operations with each other. But we don't have a tight definition for "batch operations". We don't say what you do for a merge of batch operations, etc. So you could end up with 2 different outcomes from the same inputs because of the lack of tight definition.
      5. Simeon Warner - the purpose of spec is interoperability, you have a defined interface between two sets of things (clients and servers). Can you tell what is implemented? Whether you have batch in one document as a MAY or in another, that is style. How do you tell if that is an option if it is not in the main specification? 
      6. Benjamin Armintor - reflects the way the HTTP spec has grown over time, there are things that are very required and things that are less required. These pop up as separate specifications. So moving parts of the specification to an optional spec has been done.
      7. if a client needs batch operations there is no way to back-fill that need. All other things you could backfill, but atomic operations would be very hard. But if you do have atomic ops, then if you have to let the client know what operations you allow.
      8. Maryland (who needs atomic batch operations) proposed breaking out atomic operations into their own specification, then it is clear it is not a required part of Fedora. But also it addresses the issues are the lack of concrete specification to that part of the specification. This also allows the core specification to move along while atomic operations can move at its own rate.
      9. Would it make sense to specify some of the interactions (ie. HEAD) to give the client some examples of expected results.
      10. Simeon Warner - Don't need to add anything to discover atomic operations, if you send the Atomic-Start header and don't get an Atomic-ID in results then it has failed.
      11. Split atomic operations out to its own specification, or wrap in an advisory inside the core specification.
      12. Nick Ruest - There seems to be consensus around moving atomic operations to its own specification. 
      13. Those who are showing their support for moving atomic operations out, please remember to continue to show your support if/when there becomes a dissenting opinion.
    2. External-Content
      1. Fedora 3 has Managed Content, Externally Managed Content and Redirect Content. There seems to be 3 questions that need answering?
        1. Do we need to change the way the specification is around External-Content?
        2. Do we need to add support Externally Managed Content?
        3. Do we replace Redirect with Externally Managed Content? 
      2. Also, do we suggest people just use the functions of linked data to point to content where ever it is instead of using the current External-Content?
      3. Daniel Lamb - CLAW discussed this in a call, we have varying use cases. But we are internally doing some soul searching. Does this mediation need to happen at the Fedora level or can it happen at the CLAW level. We don't have consensus in our community yet, so we can't say
      4. Is the Hydra side also having the same sort of discussions regarding the Fedora spec?
      5. Esmé Cowles - I don't think there is any coordinated discussions. 
      6. Benjamin Armintor - This is something we are discussing in the former Architecture working group and I will discuss at a lightning talk at LDCX and suggest that a new Working group be struck to review the current specification and provide a Hydra specific response to the proposed specification.
      7. Will Islandora CLAW be also providing a coordinated response to the specification? Daniel Lamb - Yes that is what we are trying to do, for some reason it has just taken this week.
      8. Columbia would like Externally Managed Content, Redirect Content is not what we need. A lot of the Fedora 3 implementation require the system to have access to storage on the filesystem. This would hit a roadblock with our content very quickly.
      9. Does anyone use/have used Redirect content in Fedora 3? Esmé Cowles - we use Redirect content in Fedora 4 and we like it, if it changed to a proxied type of interaction that would be fine too. My only concern is what the client would need to make externally managed content, how do they know where to put the file?
      10. How does Fedora 3 handle creation of Externally Managed Content? Benjamin Armintor - In my experience when we were trying to mount particular devices, the process that was creating those resources had access to the filesystem. Also, the thing that we do with External-Body mime-type is not in the spirit of that HTTP specification.
      11. Do we have consensus or do we need more feedback? 
      12. Jared Whiklo - This is a larger change than atomic batch operations, it should probably go to the list for some feedback.
    3. Please consider how you look at the specification (1b) when getting involved in discussions as it can help clarify your and others points of view.
  2. Esmé Cowles - Some PR titles that are just ticket numbers, it would be nice if you could please add a brief title to help ease finding the 
  3. Who is going to LDCX - Esmé CowlesKevin FordSimeon WarnerNick RuestBenjamin ArmintorAndrew Woods
    1. Esmé Cowles - pitching a talk around remote work and how people make decisions in a distributed environment 
    2. Andrew Woods - pitching a talk around the various aspects of the Fedora API specification effort
    3. Benjamin Armintor - pitching a talk around a revived Hydra Arch Working Group... which will include establishing a community position wrt the Fedora API spec

  • No labels