Date

03 May 2017

Agenda

Attendees

Meeting notes

James Turck: Going to ignore previous action items. The main item is API specification, approach and timeline. At the last WG meeting, there was a discussion about whether the approach we were taking to the specification was correct and whether we’d be driving to an answer quickly enough for the LLC to be able to use the spec. The topic was brought up again the board meeting, so the action I’d like to take is to agree, hopefully quickly, to the approach that we’re taking. It’s been suggested that instead of having a separate subgroup, we fold that into this one. So that’s the primary goal of this session. We also have the outstanding action of the revised charter, which I still intend to carve 10 minutes out at the end for. But first let’s try to agree on the approach and timeline, and hopefully get to some technical work.

There was a discussion around technical approach, which I want go over in a nuanced way, but generally the agreement was that we need to specify an API interface of some description and then the action point to make that concrete is to have the Symphony HTML5 application use it, and the Electron client implement it, so that if you lifted the app into another container that implemented, it would work. In theory, this doesn’t require a lot of work—just specifying the API, then leaving implementation to the LLC and the container makers.

Is that broadly the approach? Any other comments.

[Unknown]: Sounds like the right approach.

James Turck: I’m interested in getting feedback from LLC about your timeframe.

Jonathan Christensen: Lynn and team are marching toward implementation as quickly as possible, but that doesn’t mean we can’t circle back if there’s good work on the spec. Most urgent thing is to just keep moving forward toward the key goal of feature parity.

James Turck: I think we’re all in agreement on that.

Lynn Neir: Here’s a link to the API specification so far from the subgroup. We’ve implemented those so far, pretty much as specified, as well as some that haven’t been specified.

Colin Eberhardt: I’m surprised to hear they’ve been implemented, as someone who wrote some of those, because they were works in progress and I didn’t know there was work being done on them.

Lynn Neir: We’re willing to revisit them if people feel they need to be changed.

James Turck: And that’s why I think it’s urgent for us to have this meeting, to sync up on this. LLC will implement because they have to, so we need to speed up our process creating the specification.

Lawrence Miller: I think that’s consistent with how standards processes work—there are usually implementations available before ratification.

Nick Kolba: I agree and I’m totally comfortable with this way of working. If Lynn’s team just documents the APIs between the container and the web app, that’s a great starting place, and the WG can work to refine them later on. Just having some documented interfaces that are agreed upon that the LLC is guaranteeing will be there in the HTML5 app is good.

Leslie Spiro: I think everyone agrees that this is positive and things are moving forward, but as Colin says, it would be good to know they were being specified as that happens, so we could give feedback. There’s no sense in which they’ve been agreed, which is fine, but it would be nice if the team could say “we’re about to add this interface, any comments?” Colin, would you agree?

Colin Eberhardt: Yeah, I think that would be the case. Just needs a little process wrapped around it to have a little review and provide feedback.

James Turck: Just one other point that I made in my email, I have a number of work commitments that means I can’t spend much time on this. Leslie offered to step up. I think we need to find the minimal possible process people can agree to, then zip through the list and do the work. It’s useful to see how these things are done in concrete terms.

Leslie Spiro: [Question about whether the group should do its work on an abstraction layer between Symphony and Electron, e.g. the ContainerJS project.]

Colin Eberhardt: My understanding is that the current goal is to get Symphony to run anywhere, which only requires a subset of the APIs that you’d need to support a larger array of applications, and we don’t want that broader goal to get in the way of the immediate goal.

Nick Kolba: Lynn, Lawrence, how complete is the API specified in Confluence in terms of what you need to do for the app?

Lynn Neir: The ones we’ve implemented are pretty complete. We may need some more specification on the ScreenSnippet API. The rest are straight forward.

Nick Kolba: Are there any other APIs you anticipate needing?

Lynn Neir: Yes, we’ve already implemented a few more: “Activate,” to bring a window to the front, and “RegisterBoundsChange,” which allows a JavaScript web app to be notified when a child window’s size or position changes.

Colin Eberhardt: How are you opening windows since that’s not specified in Electron’s API?

Lynn Neir: We’re using window.open(), which is available in Electron. Gives us good backward compatibility, since we used that with Minuet as well.

Brian Ingenito: window.open() works in all of the containers – Electron, Minuet, and OpenFin.

Lynn Neir: We’re also implementing a method to support ScreenSharing – to get a list of all the Windows on the desktop, and a thumbnail of them. There’s a pull request open for it.

Nick Kolba: Will the ScreenSharing capability be open source?

Lynn Neir: It’s implemented in Symphony, all we use JavaScript for is to hand off a list of media sources, IDs, and thumbnails. It’s similar to the Desktop Capturer API. That’s what we have so far, there are more coming, including an interface to implement a protocol handler, to signal back to Symphony that a URI was opened.

Nick Kolba: For custom protocol handlers?

Lynn Neir: Yeah, so in IE someone could have a “symphony://” URI to bring up a Symphony room.

Nick Kolba: Is that an API between the HTML5 app and the container?

Lynn Neir: The container passes the information back to the HTML5 app.

Aaron Williamson: Can you put together a list of the API methods that you intended to implement and put them online where others can collaborate on them?

Lynn Neir: Yeah, we can put them in the Confluence page.

James Turck: Leslie, since you volunteered to help run this, what process do you want to use for proposing, reviewing, and approving new API elements?

Leslie Spiro: What’s most needed is people to write code. We’ll be putting a developer on this in the next couple of weeks, so maybe we should work out who can give developers and when?

James Turck: Do we need developers to specify the API?

Leslie Spiro: I think so.

Aaron Williamson: It sounds like Lynn and team are implementing as fast as the group can produce specs, so maybe the work that needs to be done is on specification rather than implementation.

James Turck: That was sort of my point.

Nick Kolba: Lynn, would someone be able to take the implementation you have and put it in a different container? Or are there landmines that you know about?

Colin Eberhardt: The code we’ve contributed from Scott Logic should be a good proof of concept for this.

Nick Kolba: I think the real question is, if someone wrote an Electron-based container from scratch, implements those 4 APIs we’ve discussed, and loads the Symphony web app, will Symphony hook up to those and run, or will the undocumented ones break the app?

Lynn Neir: That’s the theory. The code that implements these APIs on the web app side hasn’t been released, and that would make it easier, but you should still be able to connect with them and run the app. I’m sure there could be hiccups and adjustments needed, but that’s how it goes.

James Turck: From the perspective of the implementers, you’re the only ones who can test it.

Lynn Neir: Some of the Electron APIs will be in our .46 release.

Colin Eberhardt: It shouldn’t have to be open source to test this.

Lynn Neir: No, but it would be easier. We’re not working off the production Symphony code, because it doesn’t have these Electron APIs—we’re building those as we build Symphony Electron.

James Turck: So on our side of the fence, all we can do is build an implementations, then compliance tests that exercise those implementations, hopefully reducing the number of issues once the code is running in production. So I guess an approach is, with Lynn’s list, we could agree on the interface, then the real coding is building compliance test and implementations in other containers.

Lynn Neir: There is a demo in the code we’ve released that uses all of these interfaces – a simple test harness.

James Turck: I think we could build out on that. And we’re slightly better off in that, since Lynn is building both the open source container and closed source API code, if someone else runs into problems with their implementation, it probably means that Lynn has made assumptions in the APIs that aren’t clear from the spec. So I guess the process is for us to take this list from Lynn and start doing some work between meetings to help the LLC team out.

Leslie Spiro: I’m wondering whether Morgan Stanley is intending to track this in their container. And whether others are interested in doing so.

Aaron Satlow: We’re definitely interested and we’re experimenting with an implementation. And we’re releasing as open source a typescript API interface definition that targets a container.

Leslie Spiro: Will that be a separate project?

Aaron Williamson: Yes, this will be released as a Morgan Stanley project on GitHub.

Brian Ingenito: This is what we’re doing to enable our own apps to be cross-container. It would be very easy to just adapt to these SSF API calls, to just bridge it over, so that any app using our existing API would work, and any app using the SSF API would just go through our bridge.

Leslie Spiro: Any chance of you using ContainerJS?

Brian Ingenito: Yeah, that’s one possibility. A big part of our reason for open sourcing this is just getting it out there so others can finally see it and discuss in the open how to move forward.

Lawrence Miller: You might consider using a Foundation Github repo.

Brian Ingenito: As funny as it sounds, that’s actually a little more difficult process.

Peter Monks: It doesn’t have to be either/or – it could be a two-step process. Release it into a Morgan Stanley repo then transfer it to the Foundation at a later date once that makes sense.

Brian Ingenito: This is all coming from last Friday’s meeting, where we all decided to just open source our stuff so we can talk about it.

Leslie Spiro: Yeah, and we’re looking at similar questions around what to open source and when.

James Turck: Ok, can we try to drive this forward and see where we can get? Define a process for how to move forward with things once Lynn’s list is up. Leslie, can you whip people to make sure the work gets done?

Leslie Spiro: Yes.

James Turck: There was some comment on the proposed charter. It’s on the Confluence site. There are a couple of comments, from Colin and Nick. Not sure if anyone else had a chance to look? Here’s the link. Does anybody else have any other comments or feedback?

Colin Eberhardt: I’ll summarize my comments: I just wanted to reword to make it a little less ambiguous as to what apps other than Symphony the group would be supporting.

James Turck: Yes, I can see that. I agree there’s some ambiguity. Nick, do you want to talk about your comment?

Nick Kolba: Yeah, I was just trying to tighten up the language as well around the integration of the Symphony app into multiple containers.

Colin Eberhardt: I thought yours was more about changing the sentiment slightly, so that it doesn’t encompass other applications like Symphony, but Symphony alone.

Nick Kolba: Yeah, that’s the primary focus.

Lawrence Miller: I’m not sure why we’d want to exclude a broader objective even if the focus is on the immediate objective.

James Turck: I think everyone agrees that we want to prioritize putting Symphony in multiple containers.

Leslie Spiro: Are non-Electron wrappers going to be supported?

Lawrence Miller: I don’t think that level of specificity belongs in the charter.

Jonathan Christensen: I’ve always assumed non-Electron wrappers would be supported somehow.

Lawrence Miller: I’d think the topic of how to accomplish portability would be something the WG would address without it needing to be encoded in the charter.

Leslie Spiro: Lynn, are you abstracted away from Electron or are you using Electron functions where they’re available?

Lynn Neir: The web app API doesn’t use any Electron stuff. Of course our implementation does. We don’t call any Electron stuff from our Symphony app, because we’ve turned off Node integration in order to run in a sandbox.

James Turck: I’ll update the draft charter again, possibly to add a separate point to emphasize the prioritization question.

Action items

• Lynn Neir (Deactivated): add new/in-progress API methods to list in Confluence
• 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

Actions items from previous meetings

• Former user (Deleted): revise draft charter item 3 to focus WG's interoperability mission to desktop interop only.
• Former user (Deleted): work internally at DB to ready interbank interop project for presentation to WG
• Jonathan Christensen: add the existing Symphony Electron container backlog & roadmap to the WG Github project.
• Lawrence Miller (Deactivated): talk to JC regarding getting the Symphony front end development team engaged on the standard API work generally, and the notification API specifically.
  
  • Colin Eberhardt (He/Him) would like to have a call with JC to discuss these topics
• Former user (Deleted): put a clear description in Confluence of what information and cooperation the Working Group needs from Symphony LLC to make progress.
  • All: review and comment on Nick's description
• Former user (Deleted): bring the issue to the ESCo at next week's meeting
• Former user (Deleted) and Former user (Deleted): prepare a briefing for the April 19 board meeting
• Mazy Dar: propose revisions to the draft charter to narrow WG's mandate
• All: add agenda items to next meeting (standing action item)