Table of Contents

Date

17 May 2017

Attendees

Actions items from previous meetings

• Lynn Neir (Deactivated): add planned (but not in-progress) API methods to list in Confluence
• Former user (Deleted): revise proposed charter to clarify that group's priority is portability of Symphony to various containers, with portability of other apps being a secondary goal.
• Leslie Spiro: whip member participation to review & give feedback on proposed API spec
• All Members: review & provide feedback on draft API specification

Agenda

Meeting notes

Leslie Spiro: I sent around an email describing what I believe is the consensus view of how we ought to operate. What it says is that the Symphony web app UI should be able to run on multiple containers, including Symphony Electron, OpenFin, and in-house containers. So the thing we haven’t explicitly discussed is that support for new containers should not require a new release from Symphony. In ContainerJS, the implementation is injected into the Electron call as a pre-loaded JS piece. And I assume other containers can do something similar.

 Aaron Williamson: Can you say more about what ContainerJS is and does?

Leslie Spiro: There is a definition of a desktop wrapper API (in Confluence), the Symphony Electron implementation, and the ContainerJS implementation that will target the browser, Electron, and OpenFin. So if we design a method like ScreenSnippet, the container needs code to implement that. So if Lynn’s team ships their API focused on Electron and we want to run it on OpenFin or MS’s container, the question is, how do they make that implementation of the desktop wrapper API available? One option is that they host various implementation files, but that defeats the goal of enabling third parties to produce containers without Symphony knowing about them. What Colin did was to inject the implementation detail so the web app doesn’t have to be aware of it.

Colin Eberhardt: ContainerJS is intended to implement the Symphony API, but also interface with OpenFin and other containers.

Nick Kolba: Going back to previous conversations: Lynn has been documenting the APIs. We have access to implementations in the open source Electron side, but not to the web app that supports those APIs, because you need an LLC developer ID to access those.

Colin Eberhardt: You don’t need that. You can build tests to verify an implementation against the API.

Nick Kolba: What I’m interested in is having a contract with Symphony.

Lawrence Miller: What do you mean by a contract?

Colin Eberhardt: Are you concerned they might be implementing something other than the published API?

Nick Kolba: Well Symphony is moving rapidly to implement stuff, so all I’m saying is that, unless we’re verifying APIs against the Symphony app, I don’t have evidence that we’re in coordination.

Leslie Spiro: What you want is sensible but not achievable. What Lynn is saying is, these are the only non-HTML5 functions I’m calling. And it’s our job to review those and push back as needed to support our use cases. We at Tick42 have a developer, Kiril, who will be checking that Electron and ContainerJS are in sync. And hopefully before Symphony releases the next version of the web app, they can try it with ContainerJS, but I think anything else is impractical given the LLC’s velocity.

Colin Eberhardt: I’m happy to trust the guys working on the Symphony UI to do the right thing. They might make the odd mistake, but that’s inevitable.

Nick Kolba: My main point was, are we going to say in this WG that ContainerJS is the only implementation?

Leslie Spiro: No, we’re working in two streams. In one, we’re agreeing on the desktop wrapper API—core and extended. Core is what Lynn uses, extended is whatever else we want to add. Electron will implement only the core API—that’s the first stream. It should also be possible to create alternative, extended versions of the wrapper API. That’s what ContainerJS is, the second stream. So there’s a separate conversation with Lynn to discuss this pre-loading of alternative implementations, including ContainerJS, which would allow any container vendor to run the new Symphony UI in their container.

Nick Kolba: So you use preload scripts to embed the SSF API in your implementation today. So any container could use the same functionality to embed their own implementation.

Colin Eberhardt: With ContainerJS we have proof that this works right now. If Symphony’s app calls only what’s in the core API, it should then work with ContainerJS, which by definition means it will work on OpenFin.

Nick Kolba: No doubt. So what’s the timeframe for the web application supporting SSF APIs to be available?

Lynn Neir: Hard to commit to a timeframe right now. But portions will be available in our next release sometime in June. The full thing will not be available until the release after that, our 47 release. At least that’s likely.

Nick Kolba: But even with a partial release in June, we should be able to test out some of these API methods, right?

Lynn Neir: Yeah a few of them are in there already but I’d have to take a look to get a full list.

Leslie Spiro: Lynn, what’s your deployment model for the Symphony UI? Are you hosting the HTML5 stuff on a Symphony server?

Lynn Neir: Same as ever, each customer will have their own pod that’s delivering the HTML5 frontend.

Lawrence Miller: From a security perspective, we probably couldn’t host any portion of that elsewhere.

Leslie Spiro: Will you assume that the bank has installed the appropriate version of Symphony Electron?

Lynn Neir: They’ll have to have.

Colin Eberhardt: That doesn’t seem correct. All your code relies on is the presence of the SSF code with the appropriate version number.

Leslie Spiro: My expectation is that you’d be hosting your version of the SSF code on the same server?

Lynn Neir: No, the SSF API is shipped with Electron.

Colin Eberhardt: The Symphony Electron project will inject the SSF global with our APIs in it. ContainerJS will be a separate executable that also contains the SSF global.

Lynn Neir: Yeah, you point the Electron instance at the URL for the frontend JavaScript code. If you want to make changes to the SSF API code in Electron, you’d need to release a new version of Electron.

Gareth Davies: That stuff has to be locally installed or it won’t work.

Colin Eberhardt: And that’s what we do with ContainerJS.

Leslie Spiro: I think, then, we’re in agreement about the scope of the wrapper API – how it will be distributed and the fact that ContainerJS is just one implementation and there will be others, including Electron and bank-specific implementations. So the first thing we want to do is have Kiril check that all of the specifications look the same, then he’ll work with others on the project (mostly Scott Logic) to implement missing methods.

Colin Eberhardt: He’ll find some differences, but I’m happy that we’ve got the same principles in mind.

Leslie Spiro: Lynn, are there many more methods you think you’ll be adding?

Lynn Neir: Not many. We have one potential one, but I’m not sure it will be used. That one’s on file-download experience. And that’s the only one I see here right now.

Leslie Spiro: I’d rather get methods you might use defined early then not use them than get them too late.

Lynn Neir: I’m still waiting for the product designers to define the experience so I can define the API.

Colin Eberhardt: We’ve got some methods defined in the Confluence page. I think we need a way to mark when everyone’s agreed/signed off on them.

Peter Monks: We’ve had similar discussions on ESCo, and the way we do that is to put an info box on the bottom of the page to say whether there’s been a vote and when the thing has been ratified.

Colin Eberhardt: I think we need something lightweight.

Lawrence Miller: There’s precedent in ESCo for how to handle quorum and voting, but we’ve done everything by consensus, which I’m in favor of using here too. I think that’s the right way to get buy-in.

Colin Eberhardt: Should a small group of us get to work on some easy wins, so we can show progress?

Leslie Spiro: Do any of you who haven’t spoken have a view about what we’re talking about? Does this align with your expectations?

Matthew Gardner: I’ve been missing these meetings, but it sounds like tremendous progress and I’m very happy.

Leslie Spiro: Do you have an in-house container?

Matthew Gardner: We’re still using Paragon. We’re interested in running the new frontend in our own wrapper, but I’m tempted to use Electron if that’s what Symphony’s moving to.

Brian Ingenito: Not to muddy the waters, but we put our DesktopJS project on Github this week. I’ll send a link to the Working Group with a little blurb.

Leslie Spiro: Our main question would be whether you’ve got extra methods. If it’s not a simple mapping to what we’ve defined, we should look at whether we should implement those.

Brian Ingenito: The main difference is that you can use this on the renderer side—you’re just including the JavaScript. The only other thing to add is that there’s an implementation of the API that we register for our own internal container.

Colin Eberhardt: DesktopJS is very similar to ContainerJS, with slight differences in approach. It’s great to see it in the open. Maybe they can be merged in the future, although I think they have different aims.

Leslie Spiro: Slava from DB, does this match what you’re expecting, any DB angles?

Slava Kryukov: Definitely matches our interests. We should volunteer to be a guinea pig for the new APIs. We’ve got our own container so we should do a test implementation. I also wanted to mention, I had an action item re: interbank interoperability, and I’ve got clearance on that so I can discuss it at the next meeting.

Aaron Williamson: That’s great, I’ll put it on the agenda for the next meeting. If you could share something over the list in the meantime, that would be great.

Slava Kryukov: Yep, no problem.

Leslie Spiro: So do we want to finish here? For the next meeting, I think we wanted to make sure that Confluence has a complete set of methods and to get those signed off on. There were two open questions Colin raised, but maybe it would be best to have the time before the next meeting to review those and agree on them.

Colin Eberhardt: I like that approach. Starting with progress and coming to some agreement before focusing on disagreements.

Leslie Spiro: Ok, that covers things from my side.

Action items

• Lynn Neir (Deactivated), Former user (Deleted), Leslie Spiro, and Kiril (Tick42)
  • Compare the API definitions in Confluence with the Symphony Electron, ContainerJS, and DesktopJS implementations, agree on a single set of method definitions, and update the Confluence definitions.
  • Propose an approval process for updated definitions
• Lynn Neir (Deactivated): if ContainerJS is available before next web app release, try to test the two together
• Brian Ingenito (Unlicensed): send an email to the mailing list introducing Morgan Stanley's work on DesktopJS
• Former user (Deleted): prepare a presentation on Synapse for the next WG meeting
•