...
Attendees
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.
Slava: 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.
Slava: 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.
Slava: 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.
...