2015-12-11 - Fedora API Extensions Meeting

Dial In Details

Date: Friday December 11, 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

Discuss/prioritize initial list of High-level Requirements
1. Pick a list of requirements that could potentially drive first sprint(s)
2. See comments on high-level requirements page:
  1. Are deployment-related issues appropriate as requirements, or are they goals?
    1. If they are goals, do we have other items that are also goals, but not requirements?
  2. Is it appropriate for an API-X extension to use native java APIs such as fcrepo-kernel-api, or should they use standardized and codified fedora HTTP APIs?
Discuss list of potential Proof of Concept ideas. Do we want to pursue one or more of these as a team? Individually?
Rough implementation timeline

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

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

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