Date: Thursday, August 18, 1pm EDT (-4 UTC)
Ratify non-developer overview doc.
Ruth: Initial round of comments and feedback on the document. No more new comments coming. Is probably ready to move the document into its final place
It could go in github (or github wiki), but given the technical orientation of github docs, confluence makes sense
TODO: Move it to wiki
Service Discovery and Binding & Execution documents:
Execution doc:
More details on how execution engine will behave should/will be addressed in the implementation of the engine itself, in operational level documentation that would be released along with the implementation
Elliot addressed concern over inconsistent uses of verbiage in the doc, suggest that they are made consistent to aid reader’s understanding
Service Discovery and Binding:
Elliot will work on wordsmithing a section of this doc to make it less confusing
Ontology:
TODO: Aaron will assemble the comments relating to ontology and put them in a separate Github issue so that they can be tracked independently
Aaron Coburn suggested we pick an official namespace for use in the ontology. This decision involves the level of buy-in for the ontologies and where they live. This is a separate conversation to be had outside of this call.
TODO: Create github issue related to stewardship of ontology (namespace, guaranteeing resolvability, etc)
Indexing and messaging:
Aaron B. updated a text in this section in response to Aaron C’s comment.
TODO: create a GitHub issue for statistic reporting (e.g. request latency, execution time, etc)
Closing design related documents:
Elliot: Should close the loop on the comments thread in the document. Capture the comments in the github issues and their resolution
TODO: Aaron B. will commit the design doc into GitHub put in a comment summarizing the comments threads and their resolution
Reviewing PR
Initial PR does not include any performance optimization consideration
If Karaf is used for deployment then PaxExam needs to be used for testing
Is Karaf a deployment target for API-X? YES
Going from OSGi into a more traditional monolithic environment is easier than going the opposite direction
For the time being, we’ll continue with this approach until it presents a problem
Aaron B will continue development on a different branch while waiting for PR review