Versions Compared

Old Version 11

changes.mady.by.user Aaron Williamson

Saved on

compared with

New Version Current

changes.mady.by.user Aaron Williamson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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