...
- POC implementation
- Please look at Unknown User (acoburn)'s repository. Not many people on call have had a chance to do so
- If we agree in broad terms to the initial workflow graphs, we could start implementing proof of concepts - graphs will be a concrete starting point.
- Josh: Code & diagrams are helpful for putting these abstract conversations into concrete, understandable terms
- Which one(s) we implement first would depend on development time
- Diagrams from Stefano have broad interest and applicability
- Elliot: Agree with the approach of code & diagrams. At this point diagrams have been most helpful
- Proposes a discoverability workflow diagram, maybe based on Aaron C's POC
- Shall we put diagram source(s) and code in github? Has been a good pattern for PCDM effort
- Shall we use personal/institutional repos, or request a repo in fcrepo-labs?
- Broad agreement that fcrepo-labs make sense
- Action item: Aaron Birkland to contact Andrew Woods, see what's necessary to make this happen
- Use this github repo for POC code and diagrams
- Shall we use personal/institutional repos, or request a repo in fcrepo-labs?
- Review initial workflow graphs
- API-X would establish which extensions apply to a given request, then determine which conditions apply
- Stefano: Could be based on payload of request (e.g. headers), URI, object properties
- Discussion of "validation pass" workflow in API-X core column
- Stefano: Ideally, business logic in an extension would be enacted mostly through configuration, specialized code in validation service
- Therefore, SD&B should describe response from validation service, which API-X core can then interpret for pass/fail
- Elliot: Other option on the table is for validation extension to make the decision.
- Do we really want API-X core to understand a domain-specific response?
- Aaron: Focusing on this specific area of workflow would make sense as an activity in the next couple weeks, to understand and weigh consequences of the two approaches
- Maybe write some code and/or create illustrations of what kind of information SD&B may provide, and how API-X would use it
- Stefano: The two approaches may not be that different fundamentally
- Dan: May be able to list how each approach conceptualizes the services in the core (router, means to execute services, etc)
- Stefano: Ideally, business logic in an extension would be enacted mostly through configuration, specialized code in validation service
- Elliot: It would be useful to depict representations of incoming requests, like essential parts of URIs and HTTP bodies
- Aaron: We should also focus on diagramming contents of "verify conditions" box
- This will touch upon how "descriptive binding" discussed on the last call will play into the big picture
- Jared: We have similar use cases, like the concrete examples and diagrams to understand how API-X works
- Activities for the next two weeks:
- Exploration into "validation pass," illustrate the two approaches discussed to help further discission
- Be more explicit about contents of requests
- Diagram contents of "verify conditions" box
- API-X would establish which extensions apply to a given request, then determine which conditions apply
- Revisit SD&B
- Activities identified from "review initial workflow graphs" will touch upon this topic
- Dan "Find, bind, and execute", can't discuss find and bind without execute
- SSWAP defines invocation model, describes input and output types
- Aaron: SSWAP may be relevant to the "validation pass" option where API-X core introspects into validation response. where SD&B would need to describe responses so that API-X can act on them in some way
- the other option doesn't necessarily have API-X core needing to understand response at all
- Activities for next two weeks will help make needs more concrete
- OR '16 Aaron Birkland to incorporate comments, submit API-X entry
Next meeting
Fri. Feb 19, same time (in two weeks)