Date: Friday December 11, 2pm EST (-5 UTC)
Design Page (with use cases outline)
2015-11-13 - Fedora API Extensions Meeting
Agenda Item 1: Review of proposed High Level Requirements
High Level Requirements 1a-e
A.B. enumerated requirements, acknowledging the wiki comment thread suggesting that some of them don’t belong as a high-level requirements
R.D. agreed, pointed out that the “-ilities” are acceptable, but specific technologies (e.g. OSGi) weren’t
A.W. direction of Fedora is to clearly specify RESTful APIs (defining what Fedora _is_) and allows development of additional Fedora _implementations_ (emphasis added)
A.W. posed the question: Do we want an API that is bound to a reference implementation of Fedora (or any Fedora implementation for that matter)?
S.C. API-X should be deployable anywhere, be able to execute extensions written in various languages (e.g. python or another non-java impl). The requirements are too implementation specific.
A.C. 1a, 1d, OK. Rest of them seem to be limiting implementation choices.
A.W. Proposed that 1b, 1c, 1e be considered as design considerations.
A.B. proposed keeping 1a and 1d as requirements, move the rest to design considerations.
A.W. proposed new requirement that API-X explicitly be required to support HTTP
(point of clarification: HTTP on the client side or HTTP on the Fedora side?)
All: discussion of a API-X framework client abstraction layer it would use to communicate with Fedora.
A.W./E.M. use of HTTP vs other transports is abstracted
E.M. allows individual deployment decisions regarding risks/benefits of using HTTP or other transports
A.B. is this abstraction layer a design goal or requirement
S.C. need hard, concrete basic requirements
R.D. supports no abstraction, use existing (robust, tested) Fedora HTTP API
A.B. consider extensions not written in Java, HTTP becomes the abstraction layer
ACTION ITEM: codify comments, revise section 1, distribute for comment
High Level Requirements 2a-d
A.B. enumerated requirements. based on discussion of requirements 1a-e, proposed dropping 2a, 2c, 2d.
E.M. proposed re-phrasing 2b to place the requirement of supporting hot deployment (removal, etc) on the API-X Framework, not the Extension.
A.C. commented that Zookeeper is another possible implementation technology, agreeing that OSGi-related requirements should be removed
ACTION ITEM: codify comments, revise section 2, distribute for comment
High Level Requirements 3a-d
A.B. enumerated requirements
E.M. proposed a requirement that API-X Framework comport with RFC 2616 and identify if or how it deviates
All: concurred
A.C. commented that at least service discovery should be HTTP
High Level Requirements 4a-f
A.W. clarify the distinctions between 4b, 4c, 4d
A.B. Short on time, proposal to amend high level requirements, distribute, and get comments. Revisit the high level requirements.
ACTION ITEM: E.M. Send out a Doodle poll for next Wed, Thur, Fri