Versions Compared

Old Version 7

changes.mady.by.user Peter Gorman

Saved on

compared with

New Version Current

changes.mady.by.user Elliot Metsger

Saved on

Key

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

...

...

2015-11-13 - Fedora API Extensions Meeting

Minutes


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