Date: Thu, 28 Mar 2024 05:56:49 -0400 (EDT) Message-ID: <369821206.27366.1711619809246@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_27365_952765419.1711619809246" ------=_Part_27365_952765419.1711619809246 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Date: Friday December 18, 11am EST (-5 UTC)
Agenda Item 1: Review initial list of High Level Requirements
A.B. Review design considerations that were extracted from = last meeting's requirements.
A.W./E.M./A.C. - changes are in-line with what was discusse= d
A.B. Review the revised list of high-level requirements for= category appropriateness and phrasing.
A.W. 1a. clarify "deploy" as the ability to deploy versus b= eing required to deploy. Requirement to interact with the framework u= sing HTTP?
A.C. HTTP might not be appropriate for interacting with the= framework in a clustered environment. But having extensions being in= voked by HTTP sounds reasonable.
A.B. Proposed adding another requirement that extensions sh= all be invoked by HTTP requests.
A.C. Proposed language that extensions are exposed as HTTP = endpoints.
E.M. 2a. commented that the current phrasing places the req= uirement on the extension; rephrase to place requirement on the framework f= or clarity
A.B. Proposes to collapse items in #2 (Extensions) into #1 = (Infrastructure), and remove "Extensions" as a category. Rename #1 to "Infr= astructure". #2 is now Patterns.
J.W. Question necessity of phrasing "outside world" in the = bullet under 1a.
A.B. Revised bullet removed text.
A.B. Review item 2, now Patterns.
E.M./A.B. proposed HTTP RFC compatibility as a design consi= deration *ACTION*
A.C. Clarified that the items in #2 Patterns are not exclus= ive
A.B. None of these requirements are exclusive, they should = be considered minimum requirements
A.B. *ACTION* to add this clarifying language to the high l= evel requirements.
A.B. Review item 3, now Service Discovery & Binding
E.M. Suggested wording change, "For a specific object in th= e repository it shall be possible to..." for 3b, 3c, 3d.
All: Concur.
A.B. Proposed keeping 3a-f, but tweak for readability.
S.C. Should extension metadata or documentation be a requir= ement?
A.B. Sees that encapsulated/implicit as a part of extension= configuration
A.B. *ACTION* Add as a design consideration extension metad= ata/configuration needed, including link to documentation
A.C. Sees 3e, f as significant requirements; how extensions= register themselves with the framework and select which objects they act o= n
A.C. Existing language is vague, but simple. Could we= , for example, define the "payload" of information that would be exchanged = between and extension and the framework for registration/deployment/de-regi= stration?
A.C. Goal to standardize how an extension registers with th= e framework
A.B. Propose to add a requirement to #1 Infrastructure that= requires a specification for the interaction between an extension and the = framework with regard to service discovery and binding.
All: Concur.
A.B. Added high level requirement 1e.
Agenda Item 2: Proof-of-Concept
A.B. Simple proofs of concept that are chosen because they = interact with the framework in different ways
S.C. Validation PoC would be simpler if deletion were not a= consideration.
A.B. Is approach of using the PoC to drive development of t= he framework useful, without digging into the details of each PoC (time con= straints).
All: Concur.
Agenda Item 3: Implementation timeline
A.B. JHU till now has been working on API-X on margin time.=
A.B. Formal time for API-X being allocated late January, ea= rly Feb.
A.B. Proposed scheduling a sprint for mid-January/beginning= of February.
A.B. Model the sprint after an exemplar like a Web AC sprin= t.
A.W. Proposed detailing the goals of the sprint, what would= be done, and then this group can discuss
E.M. Suggested a high-level roadmap would be useful
A.B. Proposed assembling the details/goals of the first spr= int and then discussing them at the next meeting
J.W. Agreed with making the spring details public. To= the degree that UMD and API-X goals align, they can contribute resources.<= /p>
A.B. Proposed next meeting Jan 8, 2pm EST.
N.R. can't make that time but indicated we shouldn't let th= at stop us from meeting.
S.C. volunteered to create a diagram that shows where API-X= sits in a Fedora-based ecosystem/infrastructure.
A.B. Concurred. Suggested some wiki gardening needs t= o take place, especially with regard to presenting a unified or single voic= e of the API-X working group that reflects the decisions made thus far.