Table of Contents

Date

31 May 2017

Actions items from previous meetings

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
Lynn Neir (Deactivated): add file download API method (and any other planned 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

Agenda

Time	Item	Who	Notes
5 min	Convene & roll call
10 min	Review action items from previous meetings		See above
15 min	Overview: "Synapse" desktop interbank interoperability project	Former user (Deleted)	Postponed
25 min	API specification: update and vote on revised definitions	Leslie Spiro, Former user (Deleted), Lynn Neir (Deactivated), Kiril Popov	The WG will review and attempt to reach consensus on updated API method definitions synthesizing the existing API definitions in Confluence and the Symphony Electron, ContainerJS, and DesktopJS implementations. Conversation will center on Kiril Popov's pull request proposing an API merging these sources.
5 min	AOB & adjourn

Meeting notes

Jonathan Christensen (JC): We’re making steady progress toward feature parity in Symphony Electron and toward our .46 release, which will introduce some of the API methods that the Electron container relies on.

Aaron Williamson (AW): Leslie, I’ll turn it over to you.

Leslie Spiro (LS): The main thing we want to cover today is how we might move forward with an interface, keeping in mind what we’ve been doing in Confluence, which is a set of methods, and what we’ve been doing in Container.JS, which is not explicitly a project of this group but which we should talk about how Symphony can use it.

AW:

Brian Ingenito (BI): I haven’t, but I’ll do it by the end of today.

AW: Ok, go ahead Leslie.

LS: I’m relatively new to this group and it’s been going on for a long time and I think we all want to see it deliver more stuff that can be used. At the last meeting we talked about producing a Javascript interface that covers what’s required for the Symphony UI to run in multiple containers. And we also saw interest in a cross-container API that would allow developers to target multiple containers.

What Kiril Popov did was to look at the individual methods here and what Colin and his team are doing with Container.JS, which has an interface spec and implementations for Electron, OpenFin, and the browser, and he produced an amended interface which is a proposal from us of what a good interface would look like. He’s taken each of the methods and defined how they would be called, and different ways they might be used in practice.

Kiril created this Typscript-based interface; before we talk about whether it’s a good interface, does everyone here agree that this is what we ought to be working on as a working group? To come up with an interface specification like this? Brian?

BI: Yeah, the implementation should be completely separate from the definition, agreed.

Johan Sandersson (JS): It makes perfect sense to me.

Lynn Neir (LN): I haven’t analyzed it, so I can’t say, but my first thought is that it seems like we’re talking about going in a totally different direction now. For our v1, we’re going to be shipping toward what we’ve already specified, but I can see using this for a v2 down the road after we’ve analyzed it. But I’m a little confused, because we had a proposed standard API, and this is completely different.

LS: No one’s saying you shouldn’t ship what you have. But I don’t know if what we have now is an API. We have methods…

LN: We had meetings on this months ago where we talked about this. What you’re doing is more generic and I’m not saying it’s a bad thing but we need to analyze it.

LS: I think there’d be no point in us going down this road if it’s not something you’d be interested in implementing it, so this depends on your review. Colin had said there would be problems around windowing if it was global function-based.

LN: Well, the API we have here was similar to the one we already had, so we could get something going quickly. So if we do a v2 where we move away from that, it would take a little bit more time.

Nick Kolba (NK): LS, do you recall the specific issues around window.open()?

LN: Even using window.open(), I proposed on the mailing list that we could include that in the SSF namespace, wrapping it so that it could be implemented in a container-specific way.

LS: Agreed, I think our feeling was that having windows as a first class object with methods made it a more useable API. And all of these things resolve. But if this is just not how you want to take the product forward, you’re totally within your rights.

LN: Not saying that, just saying I need to analyze it and make sure we can come to an agreeable solution.

LS: Mark H., what’s your view on this?

Mark Hu (MH): For the RegisterOnBoundsChange, is this a Morgan Stanley feature?

LN: No, this is measuring the size and position of all your open windows.

LS: The question we’re asking everyone is whether Container.JS, which makes windows a first-order object with its own methods, is the right direction, or whether we should continue down the existing road of having a bunch of global functions.

MH: I can see that being useful.

LS: Nick?

NK: I hear what Lynn’s saying and think we need to take that into strong consideration. I also feel like globals simplify things, because when you get into the underlying implementations in each of these containers, they have their own representations of these things. OpenFin already does all of this in a different way than Container.JS is planning to. So there’s value to keeping the feature set small so that we can leave the complexity up to the container implementation.

LS: Ok. And Tim?

Tim Kolecke (TK): I think it’s worthwhile. In the absence of an established API to develop against, like the HTML5 notifications API, it’s useful to have an abstraction in between, assuming Symphony is willing to adopt it.

LS: Yeah. And Peter?

Peter Monks (PM): No strong opinion, I think the devil’s in the details and it’s heavily dependent on Symphony’s release schedule.

LS: Yeah, and I think there’s a halfway house where the global wrappers are defined here… but unless they agree that it’s useful and they want to implement it, there’s no point going down this road. But my hope is that people can review this and we can put it up for discussion at the next meeting and hopefully come to agreement on whether this kind of object approach makes sense for Symphony. And if not, maybe it’s still useful for people building cross-container applications.

MH: Speaking of cross-container communications, I have some questions. Are we defining the communications protocols between different containers?

LS: There was potentially going to be a presentation from Slava at DB about work they’re doing in that area, and I think it’s in the remit of this group, but it’s not what we’re discussing right now. But we’ll be discussing it at other meetings.

MH: We have use cases where we use components directly in applications in two different containers, so it would be really nice to define a standard way of passing them between containers.

LS: I think it’s a subject that needs to be discussed. Whether it will lead to another working group is an open question. Are people OK leaving this here and revisiting in the next meeting whether this is the direction we want to go? Anyone not happy with that?

Ok, in terms of the agenda, I think that means we’re on to any other business. Anyone have anything they’d like to discuss?

JS: Just one question, since you had such a good process of running through people. What are people using today for their Symphony interaction? Browser? Symphony?

MH: I use the Mobile App, Minuet, and Browser

Aaron Satlow (AS): Primarily Minuet at Morgan.

JS: We use the Paragon container and the mobile iOS app.

TK: We use Minuet, mobile, and a beta Mac container.

LS: One thing that shows is that the container is the most important desktop thing rather than the browser, which is why we’re all interested in this.

JS: Is anyone using the Symphony Windows URI?

TK: It’s not available in Mac.

LN: Yeah it’s only available in the Paragon container. In Electron, it will be available on Mac and Windows.

LS: I have one other thing. We’re interested in OBO – we have apps that we want to be able t ocommunicate via Symphony via OBO. But it also seems like the container could implement OBO functionality: these applications are use my camera, raise notifications, etc. Obviously there are security issues. But is there any appetite in the LLC for some kind of local container OBO functionality.

LN: There’s something like that already available in Paragon, called the vertex bus. I don’t think many people are using it, and the feature’s not going to be available in Electron. I thought this is what the DB thing was about.

LS: It’s an interop bus. Whether that means I can interop to the new Electron container and it will send messages on your behalf, I’m not sure that’s specified. And I think that’s down to whether LLC is willing to consider implementing that.

LN: My personal view is that it’s better to use the backend APIs.

AS: Is LLC’s strategy to get rid of that kind of interop?

LN: It won’d be available in the next version of Electron, but the strategy for that is determined by another group.

AS: We’ve looked at a couple of interesting things using that interop that are achievable via backend systems but increases the complexity. So we’re interested in that. This assumes you’re in a trusted environment and can’t just fire things across.

LN: If anyone’s interested in that I can put you in touch with the team responsible for that strategy.

AS: Ok, I’ll follow-up offline.

LS: I’m certainly interested in talking about that.

JS: We’ve looked at that. The current version is push-only, which makes sense from a security standpoint but limits what you’re able to do.

PM: I recall JC presenting on this topic late last year or early this year, so there might be information in the old meeting minutes. I’ll try to dig it up.

JS: I remember Goldman, Bill S., having a big presentation/overview of it and how they were using it internally.

Action items

Lynn Neir (Deactivated) and All: Review Tick42's proposal for a container API specification, including Leslie's email to the list and Kiril's pull request (especially the TypeScript specification), and comment on the mailing list.
Former user (Deleted) and Leslie Spiro: follow up with Lynn Neir (Deactivated) to discuss Symphony LLC's strategy regarding Symphony Electron desktop interop/on-behalf-of functionality.
Peter Monks: find and circulate notes from the meeting where JC presented Minuet's desktop interoperability functionality at a previous working group meeting.

Attendees

Name	Organisation	Present / Absent
Former user (Deleted) (chair)	Credit Suisse
Leslie Spiro (interim chair)	Tick42	Y
Jonathan Christensen	Symphony LLC	Y
Andrew Christie	Ipreo
Gareth Davies	Goldman Sachs
Colin Eberhardt (He/Him)	ScottLogic
Matthew Gardner	BlackRock
Mark Hu	Citi	Y
Brian Ingenito	Morgan Stanley	Y
Richard Kleter	Deutsche Bank
Former user (Deleted)	OpenFin	Y
Former user (Deleted)	Citadel	Y
Former user (Deleted)	Deutsche Bank
Adam Lancaster	Tick42	Y
Ian J. McDermott	JP Morgan
Lawrence Miller (Deactivated)	Symphony LLC
Lynn Neir (Deactivated)	Symphony LLC	Y
Ed Sanders	JP Morgan
Johan Sandersson	FactSet	Y
Former user (Deleted)	Morgan Stanley	Y
Former user (Deleted)	HSBC
Ryan Sharp	ChartIQ
Former user (Deleted)	Symphony Software Foundation
Peter Monks	Symphony Software Foundation	Y
Aaron Williamson	Symphony Software Foundation	Y