Page History

...

Review the use case for composite (referred to as "chaining" in the previous meeting) services

Attendees

• Aaron Birkland
• Unknown User (acoburn)
• Stefano Cossu
• Ruth Duerr
• Bethany Seeger
• Joshua Westgard

Agenda

1. Ratify initial list  of "what to distill from use cases". (Aaron Birkland)
2. Refined validation use cases from Stefano Cossu
   1. Enforce validation across repository
   2. Optional validation
   3. Validation only for selected resources
3. Role of API-X for supporting transactions (??)
   1. Actor models - having the API-X (or an extension) be an actor
   2. Transactions as a core feature of the Fedora 4 platform
4. Think about composition of extensions for next meting?
5. Any Other Business
   1. Elliot away: 9/28 - 10/28

...

Previous meeting agenda, including minutes

Minutes

• Consensus on use case evaluation - let's use the proposal as-is
  • Should we create sub-pages of each use case, or edit/modify pages in place?
  • Editing in place is probably more clear
  • Decision: Edit in place
• Action item:  Everybody evaluate/reformat at least one use case
  • Unknown User (acoburn) believes that most or all of Amherst use cases can be finished by next call
  • Joshua Westgard will adopt deposit/ingest related use case
  • Aaron Birkland will work with Ruth Duerr for ESIP use case.
  • Stefano Cossu may add additional AIC use case related to notifying clients when depositing duplicate binary resources
• Validation use cases - discussion around whether validation extension would be 'globally on' (with the means to configure it to disable validation where it's not wanteed), or a hook to have API-X invoke validation extension or not
  • Decided to just go with 'globally on'
• Actor model seems well suited to API-X
  • Extension is autonomous 'actor' that does everything for you
  • Client interacts with it via message passing (e.g. POST a list of resources to be ingested)
  • Actor does all the heavy lifting (possibly employing transactions with Fedora) and responds
  • Client wouldn't be aware of transactions
  • For concurrency, actor could possibly be a single thread + queue, all operations serialized
  • API-X framework would largely be agnostic about what's going on in an extension, so we're taking about what occurs within an extension when it's handling a user request.
• Aaron to find out more about Hydra use cases
• Meeting on the 23rd may be problematic, will send out poll to see if another date better