(Notes courtesy of Aaron Williamson, with additional notes from Paul Whitby)
Notes
Agenda
- Request to change the name of the program
- Review goals of the program
- Roadmap
Name change request
Leslie: interested in changing the name of the program because we want the name of our cross-container variant of FDC3 to contain the words "FINOS" and "Interop" but otherwise don't care what it is. The naming convention from the Foundation is FINOS [Program Name] Interop API, but it doesn't make sense to call it the Plexus interop API.
Aaron: our concern is just that there's no confusion that the interop API coming out of this program isn't the only interop API coming out of FINOS. So it doesn't have to contain the program name (Plexus or otherwise), it just can't suggest it's more "primary" than the FDC3 interop API.
Paul: Then we'll take this back to the private mailing list for further discussion.
Goals of Program
Anton: don't talk about wider adoption, what the purpose of the API is, etc. They look like a subset of what our goals currently are.
Slava: I agree. They mention the API, but we've more to a focus on standards and the API spec, which for us is more important, the implementation being a supporting project. The other things that's missing is our approach to community. Who is the audience? All Fintechs? Pretrade architecture? The producers or big stakeholders of complex multifunctional platforms for interoperability and distribution? If we want to increase our reach, we need to be clearer about which group we're trying to reach. Third, we should undertake a review of the functional areas we want to cover and ensure we don't overlap with FDC3's API and, where we do, why we overlap and to be explicit about where we extend the scope of FDC3. And finally, recording the new structure of projects and working groups.
AntonSlava: I agree, and that's on the agenda as well, so thank you for that reminder.
Leslie: for us, the program is about desktop interop technologies, APIs, and technologies.
AntonSlava: it's kind of a long conversation because it's more of RPC than bus. What you said makes sense in principle, but the wording is crucial and could be sensitive so it's worth due consideration.
Leslie: It's not just RPC because it's streaming.
AntonSlava: it's broader than RPC or bus, but I lack the proper word.
Saori: we've talked about multiple-broker, multiple-agent, which is not something FDC3 is really addressing. You could say multiple-bus, but that's a little too technical.
Leslie: multiple agent makes sense, because what we're doing is below that so it makes sense as an umbrella.
Paul: we agreed to take the naming issue back to the list, but it sounds like we're agreed that the goals are outdated and need to be updated, so I'll take an action to propose an update to the goals.
Saori: does a change of charter require approval beyond the PMC? [Action for Aaron: add to FAQ and PGP)
Aaron: if they're fundamental to the Program's purpose, I think we'd want the board to approve them. But if it's just a matter of adjusting the goals to reflect how the program has evolved, and doesn't move into the territory of another Program I don't think that's necessary. Happy to provide guidance.
Slava: does everyone agree that if there's an implementation of interop API that it would be hosted under this program?
Leslie: if we open source our implementation as a reference implementation then absolutely we'd do it here, but we haven't decided that yet.
Slava: if we're reaching out to the community about this API, then I think we have to provide a place for collaboration on an implementation that's not controlled by the platform owners. Maybe we'd just add an additional repo. But we can come back to that. And it would be great to have the Tick42 implementation 🙂
Leslie: haha, well it would just be a layer between the FINOS and Glue42 methods.
Slava: I think the idea is that it demonstrates credibility of this API, by proving that this specification works with the platforms, and a reference implementation is the best way to do that. That's certainly been the focus of my discussions with one group, who was having trouble making the connection between this specification and their software. Just an idea.
Paul: that's a great proposal, Slava, and I agree it's a good thing for members to consider. And if someone steps forward, we'll host it.
Slava: and it would also be good to have a shim to extend Plexus along the lines of this spec.
Roadmap
Paul: a roadmap
2019 Roadmap was proposed at the last meeting, with proposals for Q1, Q2, and H2. And some additional goals came up that were captured separately.
Q1
Work on spec
Support interop across the industry
Add extension points for runtime interop stats to be gathered
Continued development of cross-bus API specification
Moving confluence docs to GitHub pages
Review alignment with FDC3 standards
Implementation of FDC3 API in Glue42 and Plexus
Q2
Simplified JS client API
Review alignment with FDC3 standards (cont'd)
H2
Implement broker on NodeJS in addition to current .NET implementation
Review alignment with FDC3 standards (cont'd)
Slava: on alignment with FDC3, it's reiterating that whatever we do, we should align the work in different groups with FDC3 and, where there's overlap, we should be very clear on the reasons. This is more reiterating a commitment than a separate workstream.
Leslie: we'll be releasing, hopefully by the end of March, an open source implementation of the FDC3 API and the interop piece, demonstrating that they exist at different layers.
Anton: if you have a corporate GitHub that's open, we're happy to review.
Leslie: as soon as it's a coherent whole, we'll do that. We should add to Q2: define API language bindings for .NET and possibly Java.
Slava: is that part of API or API client?
Leslie: well, now the language bindings are javascript. We'd like to have them in other languages. We also want to add pubsub and support for what we call "context channel" to the API in Q1.
Slava: we want to replace the Plexus broker protocol, which is currently written in .NET, to Node, because it's more popular and easier to support.
Anton: I think it's a good idea to do reference implementations in Electron or something that supports NodeJS because it enables implementation by a wider variety of containers and increases the standard's reach to a wider community.
Paul: anything major missing from this roadmap?
Leslie: no. [Action on Paul to update the roadmap]
Saori: no. I don't know if this fits, but do we need a dedicated adoption campaign working group or is this something that will naturally happen between our firms on a business-as-usual kind of way?
Paul: I think that's a really good idea.
Leslie: we're certainly doing this as part of our messaging.
Anton: we are doing this as well to partners and providers and agree we need more focus on this.
Paul: sounds like we need two more working groups: plexus open source implementation (existing); manage the API as distinct from any implementation (new); driving adoption (new).
It says in the governance handbook that I should be striving for consensus in decision-making. So, does anyone object to these working groups being created?
[No objections] [Decision made]
Leslie: can we also prepose chairs of working groups?
Paul: I propose Anton (Plexus); Leslie (API); Saori (Adoption). Does that work? [Action on Paul to add new WGs to the wiki – Done]
Saori: sure.
Leslie: Rob suggested in chat that adoption be explicitly made part of the Program Roadmap.
Saori: that should be the first order of business of the Adoption WG. [Action on Saori]
Paul: we're out of time.
Leslie: Slava and Anton, re: the API WG, should we make the ad hoc meetings we've been having regularly every two weeks?
Slava: yes, I think that's a good idea and would help scheduling. [Action on Leslie]
Saori: I recommend getting support from FINOS on that to ensure we don't conflict with other groups and get the Webex set up.
---