...

Actions items from previous meeting

•  Jonathan Christensen: schedule update to the group on the details of the Minuet-parity work for 
•   Former user (Deleted): identify interested volunteers to work on the app → container interface standard
•  Jonathan Christensen: identify a suitable LLC engineer(s) who can discuss the high level capabilities the Symphony app requires from the container & provide Former user (Deleted) with an ETA on when development might start
  
  •  Former user (Deleted) (with assistance from Peter Monks): schedule a session with LLC engineer(s) and volunteers, to capture that list
•  Former user (Deleted): refine language in point 3, based on feedback from Leslie Spiro and the group
•  Peter Monks: introduce Former user (Deleted) to Jim Adams @ Deutsche Bank.
  
  •  Former user (Deleted): coordinate with Jim regarding presenting to this WG on how desktop integration discussions can best be facilitated
•  All: identify potential topics of conversation while we wait for JC to re-engage with the WG
•  Leslie Spiro: get in touch with Former user (Deleted) regarding "on behalf of" API capabilities
  •  Leslie Spiro: provide an update to the WG on whatever is discussed

...

Meeting notes

Action items

...

Draft Charter

Draft new Charter:

...

1. The group will seek to define and standardise APIs required to integrate the Symphony HTML5 application into a desktop container, with a specific goal such that applications such as Symphony might be hosted in different containers/frameworks. Standardisation may take the form of identifying the relevant standards (i.e. W3C standards) or authoring new standards as relevant.

2. Enable and expand the capabilities of the Symphony Desktop Container project(s) by direct contributions from the Foundation members and collaboration with Symphony LLC, in order to influence the direction of the project to meet the requirements of the Foundation members.

3. The group will seek to influence the direction of the development of the 3^rd party integration APIs used to interact with the Symphony Desktop application, both as they relate to 1 and as they evolve which may include more general desktop application interoperability either via local interfaces,  server side services, Symphony messaging etc. This influence will happen through working with Symphony LLC and direct contributions from the Foundation memebers

CHANGELOG / UPDATES:

ESCO has seen the charter and had no major objections

2 Wording updated for clarity - overall intent should be the same

3 Is still a work in progress - it is likely that we may need to work alongside a wider interop working group that is being discussed. This may mean 3 is altered to be desktop specific.

Meeting notes

• Introduction
  • James Turck: Most interested in hearing from JC about the LLC’s roadmap. Don’t want to get too deep into the charter, but a slightly updated version of the charter is in the meeting notes. Had a conversation at ESCo about it and there are no new concerns. The one outstanding item is point 3: there is talk of creating an interbank interoperability working group and we may want to adjust our charter to include working with that WG. Until that happens, we should leave point 3 as is. In the meantime, please have another look at points 1 & 2 and send me any comments.
• LLC Desktop Wrapper API roadmap
  • Jonathan Christensen: We’re lagging a bit getting the team started, but that should happen by the end of this week or Monday at the latest. Thibaud is going to be the PM responsible. We want to publish our current roadmap and issues backlog publicly. Where would be the best place for that?
  • Peter Monks: Suggest putting roadmap in the project itself as a Github wiki. The alternative is putting it into the SSF confluence under WG’s space. May be technically easier since both are Confluence.
  • James Turck: Is this the backlog for the Symphony Electron container work? I agree that Github makes sense.
  • JC: Makes sense.
  • Gareth Davies: What is the work being done?
  • JC: [shows working document]
  • JC: This section, “Feature Parity with Minuet,” shows the first features being worked on. They mostly relate to how the application works with native features of the OS.
  • JT: What this WG is interested in is how the HTML5 application exposes the API so that it can be dropped into other containers. Some may want to drop the app into containers that don’t support every feature. In that case, capability-checking needs to be done, as well as other practical things. As the API is developed, we need to be thinking about stitching it all together.
  • Nick Kolba: Totally agree. I’ve been having similar conversations with others. These workflows are common across many financial applications. What we’re interested in is defining these functions in a standard way that builds upon web standards and leveraging what’s already available from browser tech, so that the Symphony app and containers can build against supporting those standards and achieve portability within and outside Symphony world. Matt Gardner and I created a “strawman” in the WG wiki space that will give you an idea how we’ve been thinking about these things.
  • JC: The trick is how to get consensus on our approach to the API without slowing down work on the feature set. With Minuet, these features are built into a single file in the app—the idea for portability was that anybody could create a simple shim to those APIs and that functionality.
  • Mazy Dar: The main thing is to define the feature set abstractly so that, for example, a JavaScript client can raise an event for the container to handle. Between the feature set you have and various other use cases that are out there, it should be simple to get a couple of these features down, with some basics around semantics, so that we can start getting specific on what the API would look like.
  • JC: To get that moving, should we have a working session with a few of the developers, taking one feature as an example to start with?
  • JT: Yeah, that would be our suggestion—if anyone on this WG wants to join that working session, tell us and we’ll set it up. Looking at point 1 of charter, success for us is slightly different from success for Symphony at the moment—it’s not just about building out Electron container, but about supporting multiple containers.
  • JC: That’s explicitly our goal as well. We’re not prioritizing the Electron buildout over defining the API—we need to do them both at the same time. We just want to figure out best way to do both without slowing down development too much.
  • JT: One thing that needs thought from the beginning is API capability discovery and loose coupling mechanism. How does the app know what it’s running in and what the capabilities are? What, concretely, does the Symphony API do when it needs to, for example, create a toast notification? Once we’ve worked out the neat way of making that work, the rest of work is just implementation of that for a particular function.
  • JC: Makes sense.
  • Colin Eberhardt: We should identify a good starting point in the current API to explore in a deep way. Now we have the breadth—the overall scope of the API—but to really figure out how we’re going to work we need to pick one of those areas, define a specification, then create suitable polyfills for various containers and just test the API.
  • NK: Totally. And I think the toast notification use case is the most straightforward candidate.
  • JC: Ok. I’ll speak with Lynn and Thibaud today and make sure they’re enthusiastic about participating in the working group and understand the charter, and we’ll go from there.
  • JT: If you just reiterate to them the success criteria of needing to get it done in multiple places, I think that’s point one for many of the people on this group. People will be pleased if they see progress on that. I’m happy for the code-level people who want to be involved to directly set up a session with Symphony. How should we arrange that?
  • NK: Colin, Gareth, me, and Matt have been talking about that. Others should let us know if they’re interested. Then we’ll find a medium for collaborating since some don’t have Github access.
  • JT: Since not everyone is on the call, could you (NK) send an email repeating that offer? And JC, could you please forward to Lynn and Thibaud?
  • JC: Will do.
  • JT: Anything else on that?
  • JC: No.
• Outstanding action items
  
  • JT: Anything else from anyone? Peter, other actions?
  • PM: Not involving anyone on the call.
  • JT: Email me if you have comments on current draft. I will continue working through the charter and will move to a vote in the next couple of weeks if no one has further comments.
  • Matthew Gardner: Who should we contact to make sure we’re involved in the tech session?
  • JT: NK can you organize that session?
  • NK: Yes, absolutely.
  • PM: [Introduced Aaron Williamson and explained that he would serve as secretary for the next meeting.]

Action items

•  Former user (Deleted): arrange a working session involving Lynn Neir, Thibaud Duprat, and engineers from the Working Group (including Colin Eberhardt (He/Him), Matthew Gardner, and Gareth Davies) to begin work on an API specification for a single feature. 
•  Jonathan Christensen: talk to Lynn and Thibaud to encourage their active engagement with the working group and ensure that they understand the WG charter.
•  Jonathan Christensen: add the existing Symphony Electron container backlog & roadmap to the WG Github project.
•  Former user (Deleted): take further comments on the charter, finalize the draft, and bring it to a vote.
•  Former user (Deleted): coordinate with Jim regarding presenting to this WG on how desktop integration discussions can best be facilitated
•  Leslie Spiro: get in touch with Former user (Deleted) regarding "on behalf of" API capabilities
  •  Leslie Spiro: provide an update to the WG on whatever is discussed