Versions Compared

Old Version 1

changes.mady.by.user A. Soroka

Saved on

compared with

New Version Current

changes.mady.by.user Andrew Woods

Saved on

Key

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

...

Agenda

  1. Next Import/Export sprint: May 15-26... all are welcome!

  2. Question for Benjamin Armintor: What the the Columbia requirements for "external content"?

    4.6.2 and 4.7.2 releases went out

  3. Outstanding issues on Fedora API Specification

    1. Remove atomic operation section?
    2. The Columbia requirements for "external content"
  4. LDCX next week
    1. Who is coming?
    2. What topics would folks (coming or not) like to see discussed?
  5. Descriptive pull request titles
  6. ...

  7. Status of "in-flight" tickets

      Click here to expand...

...

  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. 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é Cowles, Kevin Ford, Simeon Warner, Nick Ruest, Benjamin Armintor, Andrew 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
  4. Patch release for security vulnerabilities?
    Cf. Image RemovedFCREPO-2416 .  Andrew Woods does not believe that the security vulnerabilities identified in the beanutils and struts modules pose any actual risk to Fedora but has a pull request pending to master to remove them from the war file anyway as a matter of good practice.  Do we need to backport this change to 4.x?  Consensus was that it would be good practice to do so, at least to 4.7 and 4.6.  No counter opinions were expressed.  Andrew Woods and Nick Ruest agreed to work on the patch releases over the next week and a half.  These can be expedited patch releases requiring only basic sanity testing.
  5. Many members issue.
    Cf. Image RemovedFCREPO-2416 and Many Members Performance Testing .  PR submitted by Danny Bernstein focuses on two changes related to improving retrieval performance of objects with many inbound or outbound references: (a) increasing the size of the ModeShape cache size and (b) enabling parallel streams by default in Fedora.  This will be discussed further at Monday's Performance - Scale meeting .  Andrew Woods encourages others to look at the PR and do some testing.  Esmé Cowles noted that he has continued to see performance issues with editing operations, though it's not clearly exactly what the source is.
  6. Default Fedora messaging: Change from topics to queues?
    Current default for messaging is topics.  Any counter-arguments to making queues the default?  (a) Some installations may be dependent on the current default and changing it would require some action on their behalf.  (b) If not properly configured, unattended queues can consume significant resources as they grow.  There was general consensus that, regardless of whether the default is changed or not, it would be beneficial to have an easier way to choose one or the other (currently, this requires editing a config file).  Suggestion was made to have no messaging as a third easy option to choose and perhaps make that the default.  Aaron Birkland spoke in favor of leaving topics the default, noting that topics are easier to understand than queues and anyone who wants to use queues already has to do some work to set that up.  It was pointed out that the API spec says Fedora does messaging so defaulting to no messaging is not ideal.  Decision was to leave default as it is (topics) but to add an easy way to toggle among topics, queues, and none via a system property or some such and to change the provided queues configuration to include some resource limiting configuration.  Andrew Woods will create an issue and Daniel Lamb agreed to be assigned to it.
  7. Next Import/Export Sprint.
    May 15-26.  Will focus on addressing issues raised by stakeholders testing previous work on this utility and on implementing "Phase 3" requirements, largely concerned with loss-less roundtripping of resources.  Developers, testers, and documenters are all sought for this sprint.
  8. Question about external content.
    Skipped.
  9. Fedora API spec issues.
    Cf. issues on Fedora API Specification .  A couple of these have resolutions identified and just need PR's submitted.