Versions Compared

Key

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

...

  • Word around the community seems to be spreading
  • Elliot looked at Async Storage effort's wiki pages, REST API page.  It looked very congruent with API-X use cases and intent
    • It would be reasonable for members of this group to look at their use cases
    • Aaron C:  Some use cases are a good fit, some may not be.  Seems like the best fit are for interactions that are not expressed easily in LDP or Fedora's APIs
    • Amherst has use cases related to putting objects into Glacier, completely external to Fedora
    • Andrew:  There was a module (in fcrepo-labs?) that routed requests to external stores.  Would that be useful?
      • This refers to Modeshape configuration for different binary stores, projection over filesystems
      • Modeshape can create separate buckets for binary content that can be routed to different binary stores
      • Fedora provides hints to Modeshape containing name of store to specify routing
    • Is one possible pattern for an API-X extension to intercept request, perform storage steps, and ingest a Fedora resource containing pointer to persisted location?
      • Amherst has use case similar to this (e.g. with Batch ingest).  It makes sense to write them down
  • The approach of this API-X team to take the initiative to understand other efforts in the community, then perform outreach seems like it could be a successful pattern
    • Seems to be a high degree of awareness of current efforts within this team.  Keep it up.
  • Hydra, Islandora recently floated thoughts on the nature of their interaction with Fedora.
    • May be interesting to consider how these interactions would occur if API-X existed
    • Common example is complex ingest
      • Fair amount of work on both ends related to ingest workflows
    • Unknown User (daniel-dgi) and Unknown User (escowles@ucsd.edu) spoke of similar  identifier/URI mapping problems on yesterday/s Fedora tech meeting, where business objects in Hydra or Islandora have identifiers that need a lookup to correspond to Fedora resources, and there isn't always a 1:1 mapping
    • Where it make sense to consolidate functionality or define common APIs in those communities (as discussed in e-mail threads), could API-X be of value?
      • Don't want any project to feel like they're losing anything if functionality is contained in (or exposed by) an API-X extension, nor use API-X at all if it doesn't make sense
      • Ideally their needs could inform design of API-X to make it a useful tool to them
    • Should somebody be ambassadors to Islandora/Hydra communities, at least until the API-X effort has progressed to the point where it's ready for broader conversation?
  • Validation use case spontaneously evolved into a deep dive.
    • Has tested the boundaries of what API-X needs to do
    • Highlights from Validation comments:
      • There is a synchronous/filtering use case where all requests to Fedora resources are filtered through validation extension;  deny or allow request based on validity
      • There is an asynchronous/service use case where Fedora resources expose a service (similar to fcr:fixity) for producing validation reports
      • Lots of discussion on how API-X knows when to invoke validation extension in synchronous case
        • Globally, for every request?
        • Wherever there is some marker
          • Could this marker be an rdf:type (e.g. cma:validatable)?
          • Would validation extension or API-X need to be aware of hierarchical nature of Fedora resources?
      • Separation of concerns:  What does API-X need to know what does validation extension need to know?
      • How would extension implementations interact with Fedora?  HTTP+LDP?  A client library?
        • fcrepo-kernel seems too closely tied to JCR, modeshape to allow completely external use cases (i.e. from a separate VM or host)
    • Stefano:  There seem to be three validation use cases really:
      1. Global validation across the board; do not even persist an object if invalid
      2. Persist invalid resources and do validation later
      3. Validation can be turned on/off for parts of the repository
  • We need to come up with a list of exactly what we want to distill from our ever growing list of use cases
    • Express/visualize interactions between clients, extensions, and services (Fedora, Indexes, Storage)?
    • Roles and responsibilities, e.g. what does API-X do vs extension?
    • What API-X requirements are implied by each use case?
    • What is the API-X value proposition for each use case?  Why would it make sense to implement an API-X extension to implement a use case, rather than some other pattern?
  • Action item:  Aaron Birkland: Create initial list of "what to distill from use cases".  We'll debate and ratify over the next two weeks
  • Action item:  Unknown User (acoburn):  Write down some UMass Amherst College use cases regarding async storage
  • Action item:  Stefano Cossu:  Split validation use case into the three use cases mentioned above.  The deep dive validation page would be too hard to read/understand going forward
  • Let's wait a little while longer to define roles (e.g. Stakeholder, Developer, etc).  Need to understand use cases more, see if there is more interest from community
  • Next meeting 9/25, 2 PM EDT (-4 UTC).  Andrew Woods will not be there due to travel conflict.

...