...

• Update on API Extension Architecture progress so far
  • New use cases are still being added, more are welcome
  • Focus has been on understanding use cases and role of architecture vs extension, this has proven to be a valuable exercise.  
  • validation use case has evolved into a 'deep dive' in sketching out an extension and how it might interact with the framework
• Question from Danny (Islandora):  So what is the API Extension Architecture anyway?
  • Public URIs, expose web resources in similar pattern to fcr:fixity; route requests to service/code that implements it
  • Use cases have highlighted 'filtering' pattern.  Intercept and filter incoming and outgoing requests, e.g. add link headers as in signposting
• Potential Hydra and Islandora use cases
  • Danny is in the middle right now of translating nasty URLs into Friendly URLs.  Is this a potential use case?
    • Yes, add it to the use cases page.  The more use cases, the better the design may fit needs of community
    • Don't worry about 'is this an appropriate use case'.  That question has to be asked of every use case on the page
  • Hydra has similar identifier/URI issues.  
    • Whatever the identifier scheme, mapping between application objects and repository resources is not going to be 1:1, so it's good to get a handle on that.
    • Potentially Use API Extension for Identifier lookup and URI re-writing.  
• Is there anything that can/should be pulled out of core and into an API extension
  • Transform, OAI, SWORD maybe
  • Still a little early to discuss this, API extension effort is not at the design stage yet;  would want a working product before considering its value
  • Current extension mechanism is a little awkward, i if nothing else the common interest in OSGI among various efforts could bring benefit to pluggability of existing extensions.
  • Existing patterns for async camel toolbox usage shouldn't change

...