Date: Friday February 05, 2pm EST (-5 UTC)
- Dial-in Number: (712) 775-7035
- Participant Code: 479307#
- International numbers: Conference Call Information
- You may also call in using the VoIP dialer from a web browser, or Android/iOS apps
- IRC:
- Join the #fcrepo chat room via Freenode Web IRC (enter a unique nick)
- Or point your IRC client to #fcrepo on irc.freenode.net
Meeting Goals
- Move forward on architecture/design discussions
- Understand proof-of-concept process
Attendees
- Aaron Birkland
- Daniel Davis
- Ruth Duerr
- Elliot Metsger
- Bethany Seeger
- A. Soroka
- Joshua Westgard
- Stefano Cossu
- Randall Floyd (Indiana University)
- William G. Cowan
- Jared Whiklo
- Kevin S. Clarke
- Yinlin Chen
Agenda
(see last meeting's minutes)
- PoC implementation (carried over from last week)
- Unknown User (acoburn) wrote a wireframe POC demonstrating service discovery, binding, and proxying (git repo, discussion on irc)
- Review initial workflow graphs
- Revisit Service Discovery & Binding
- "descriptive binding" beyond rdf:type
- SSWAP
- OR '16 submission
Minutes
- 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)