...

• Unknown User (acoburn)
• Bethany Seeger
• Yinlin Chen 
• Esme Cowles 
• Jared Whiklo 
• Andy Wagner
• A. Soroka
• David Wilcox
• Namita Bahulekar
• Andrew Woods
• Yinlin Chen

Agenda

1. Transaction use cases
2. 4.5.0 release status
3. Open Repositories 2016 proposals
4. Memento and Fedora are friends
5. UCSD / Hydra dev-congress topics

6. Status of "in-flight" tickets

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13202 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

...

1. Please squash a bug!

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

2. Tickets resolved this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

3. Tickets created this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

Minutes

1. Transaction use cases - Lack of consensus and we needed some more input and concrete input and discussion. 3 more transaction use cases. 
   1. ICPSR Transaction Use Cases - long running atomic operations
      1. Long running transactions. Generate DOI using external vendors, send JMS messages to replicate
      2. Something that works with a two-phase commit strategy, not currently offered in Fedora.
      3. Integrating with JTA providers, still some discussion around this.
      4. Do we want to support long running transactions? 
         1. Which could mean hours. 
         2. Current implementation supports this with a refresh to transaction timeout. 
         3. Could add a header to show the remaining time on your transaction. Which is returned when you extend your transaction already.
      5. Do we want to support two-phase commits? 
         1. Transactions are fully supported in the Camel component, if you define a route and mark it as transacted, then if any route endpoint fails then the Fedora portion will be rolled back.
         2. It's about what type of middleware you use.
         3. This is a REST API. So we will generally not add this type of feature to the Fedora API.
   2. UNSW Australia Transaction Use Case for ResData - actual offers a use case with needs beyond simple atomic operations. 
      1. Are we interested in validation in the Fedora API in anyway. A. Soroka says "hell no". 
      2. Modeshape 5 is moving towards greater levels of consistency, perhaps users that need these features can continue with that implementation. Where users which want other less consistency features can look to another implementation.
   3. Islandora CLAW Transaction Use Case - again atomic operations and durability.
      1. definitely using atomic operations.
      2. short lived transactions.
      3. no need for consistency at this time.
      4. isolation - snapshot isolation is probably sufficient, but may or may not be required at all. The concurrency of the application will have a large impact on this requirement.
      5. Islandora CLAW will discuss on next Wednesday's call.
   4. Also an old one from Islandora (Jonathan Green) and one from U Virginia which needs some input/completion can check with Michael Durbin? 
      1. The Islandora one can be removed as it is no longer valid (if it ever was) for Fedora 4.
   5. In the current Fedora implementation we have a broader transaction support, but the Fedora API might have a more limited set of atomicity and durability. However an implementation can provide additional features, but people should not expect the continued support of those optional features.
   6. We want to ensure that those organizations developing middleware have the features they need in the general specifications to ensure the long term viability of the Fedora API for their needs.
   7. Who counts as an organization in the previous point?  Organizations based around technologies or around a community (and generally a large one) which lends to continuing use. Longer term projects also have the worked longer term.
   8. Isolation need is understandable but enforcing a form needs a strong use case
   9. Consistency in the Fedora API is not currently needed by a large number of groups and present a significant roadblock to alternate implementations.
   10. Delay any response/comments/call to action on the mailing list until after the Islandora CLAW call on the January 27, 2016.
2. Release
   1. Release testing has been completed.
   2. Esmé Cowles and Nick Ruest will tag team the release.
   3. Andrew Woods will pull together release notes and JIRA tickets.
3. Open Repositories Proposals
   1. Any Fedora related proposals going forward?
   2. Andrew Woods is putting forward: A more detailed description of moving towards a cleared defined and specified API, the benefits and process involved. A. Soroka is interested in helping on this.
   3. Aaron Birkland is thinking about an API-X proposal. This would definitely have support from the current and past Fedora community.
   4. There will be a Fedora workshop, might be reasonable to have a committer meeting. Send a note to the Fedora Tech list to see who is attending OR Dublin.
   5. Performance and clustering might be good but not ready.
   6. Asynchronous integration would be a good one, but Unknown User (acoburn) will not be attending. However might write the paper which someone else could present.
4. A. Soroka feels we should start putting the Fedora API down in the wiki to give it some credence and/or allow people to react to it.
5. Memento versioning has been accepted as our strategy for versioning. 
   1. Andrew Woods had a conversation with Mike Nelson at CNI, he was interested in the prospect of a write API for Memento ????
   2. Rob Sanderson has also been involved in Memento creation and should be involved.
   3. Ben Armintor has said he might help with the design from a LDP perspective.
   4. Anyone attending the Hydra congress could meet to move the Memento project forward.
   5. Islandora community should check the specifications and make sure it fits with our use cases and respond to the thread to raise concerns or affirm consensus. Nick Ruest thinks he may have responded.
6. Hydra dev congress
   1. Update the linked wiki page to add any topics you would like discussed.
7. In-flight tickets
   1. Please continue to work your tickets.
   2. Esmé Cowles will review 

      Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1838

8. Andrew Woods will be away for the next two weeks.
   
   1. Keep fighting the good fight.