Table of Contents

Date

06 Sep 2017

Actions items

Existing

•  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.
•  Leslie Spiro: follow up with Lynn Neir (Deactivated) to discuss Symphony LLC's strategy regarding Symphony Electron desktop interop/on-behalf-of functionality.
•  

  JC & Lynn Neir (Deactivated): check whether documentation of Symphony web app API is accessible

•  Former user (Deleted)Former user (Deleted): point Colin to the fix for the Symphony windowing issue.
•  Former user (Deleted): review OpenFin code for solution to windowing issue.
  

Standing

• Jonathan Christensen: Update Working Group if Symphony's plan to release Symphony Electron by the end of the year changes.

New

•  Former user (Deleted) add detail about undocumented APIs & requirements to API documentation.

Meeting notes

Leslie Spiro: [Lists action items] First, any comments on those actions?

Nick Kolba: I can show our progress on the OpenFin Symphony container. This is Symphony running in OpenFin. We’re pretty close to feature parity at this point. We have things like popouts and notfications working. We still have to get the chime working. We also integrated the screen snippet tool, running the exact code from Minuet and using our adapters to connect to it. There’s a notification from Peter. That’s most of what we have. So it’s really quite simple in terms of what we’re doing with the code. The whole project is very small. We just have some javascript modules that get bundled into a preload script that create the API, and then we’ve got the assets, like the screen snippet tool, that’s just a node app wrapping the Minuet code. Here’s our app manifest. We have appAsset here that bundles in other executables for the app to interact with. This is all open source today in the OpenFin GitHub, and we’re working with the Foundation to move it to their GitHub.

Johan Sandersson: Are you supporting the Symphony protocol handler to open Symphony from another app (with a stream ID)?

Nick Kolba: We’re not supporting that now. That’s a Minuet feature that we didn’t spec it as part of the API. We’d have to look at how we’d expose that. We have our open protocol handlers for OpenFin, but we don’t yet have a framework for supporting custom protocol handlers. We could probably do that through an additional extension. We’ll look at that. I’m not too familiar with the implementation on the Symphony side. Does anyone else have further thoughts on that?

Johan Sandersson: I just remember that this was supposed to be part of the Symphony Electron parity roadmap, but that’s all I know.

Nick Kolba: Lawrence, do you know?

Lawrence Miller: I understand why it’s important, since it’s one of the most important external APIs, and I’m sure it’s on the roadmap, but I’m not sure where it is on Lynn’s work queue. He’s probably the best person to ask.

Nick Kolba: Ok, I’ll talk to him about that. We could definitely expose a way to register those additional protocol handlers. What I’m most interested in right now is how extensive is the business logic around processing them. I’ll follow up with Lynn separately.

Aaron Williamson: Has anything you’ve done fed back into the documentation in the wiki?

Nick Kolba: There needs to be more detail around a number of the APIs. The documentation there is too loose for someone to pick just that up and build something that’s going to work. You need to reverse-engineer a lot of the behavior. And that makes me concerned about preserving that contract going forward with the web app. To make this a sustainable effort, we need more assurance that the way the API is being spec’d is going to be more future-proof.

Leslie Spiro: Nick, could you go and add that additional detail and get Lynn to sign off on it?

Nick Kolba: We can definitely do that. I think it’s also become clear that we need either JC or someone from his team to be very involved in that process and sign-off, because they own it more than Lynn does. Because the risk of things breaking is more on the web app side than on Lynn’s side. So we need to make sure the web app’s owners are part of this process.

Lawrence Miller: Something like a clarification is probably a relatively simple improvement to make to the API. I would distinguish between things that aren’t standardized anywhere and things that are, like HTML and JavaScript. If they aren’t they probably should be.

Leslie Spiro: The gaps Nick’s discovered are specific omissions that I think we should capture and get reviewed by the relevant Symphony teams.

Nick Kolba: Right, there’s a distinction between wider Symphony standards and the contract between an application and any number of containers, which doesn’t have anything to do with standards.

Lawrence Miller: I agree with that, I think we’ve just found examples of both kinds of things.

Nick Kolba: Yeah, Colin and others were keen on having the notifications API standard be exactly the HTML5 notifications API, and simply extended. Lynn implemented it so that there’s a separate API that mimics the HTML5 API but doesn’t replace it. So that’s a place where we can have an interesting discussion about the relationship between the API and standards. Same is true of window.open(), which leads to some funny side-effects when you’re dealing with OpenFin that you don’t have with Electron.

Aaron Williamson: Does Symphony have a plan for stabilizing important API features and how to communicate changes to the API in advance to users so that things don’t break?

Lawrence Miller: I think this is the right forum for that discussion. I feel like we have a structure in place to cover that now, but I think we need to do it for the procedures to come into play. So I think we’re on the right path and need to remain vigilant about that.

Aaron Williamson: Is there anything we can do to facilitate the work of those integrating with the APIs?

Nick Kolba: One would be to create early access to the development environment for the web app for those who are developing APIs, maybe in the Foundation. That’s going to be invaluable.

Lawrence Miller: Just as an FYI, we do offer to customers UAT development environments where we offer early access and we’ve talked to the Foundation about doing the same with the Foundation pod. The conclusion out of that conversation has been that if we do that with the open developer pod, it would interfere with user expectations that the environment be stable. So you’d really need another environment. Some of the folks on this call do have UAT environments where those changes get pushed. But it all comes down to how many environments are getting pushed and what the users of those environments want.

Peter Monks: If the frontend was developed as open source, would that be an alternative way to get this done?

Nick Kolba: That would be absolutely ideal. My understanding is that that’s the LLC’s ultimate goal, but we’re some way off from that and there’s no timetable for that.

Lawrence Miller: I’ve provided an update on that several times, but even once we’re there, that’s not the same as having a running UAT environment. I don’t think the open source development will buy you as much as you want, because you still need advance notice of when changes begin running.

Peter Monks: Yeah, but it does provide advanced visibility into those features.

Nick Kolba: Right, I don’t think open source would be a magic bullet, but it would give clear visibility and the ability to influence the interface from both sides, which is what’s currently lacking. But we’d still want at UAT environment where we could test end-to-end.

Leslie Spiro: Any update on the Plexus contribution?

Peter Monks: A CONTRIB came in from the DB team, so they’ve started the contribution process. We’ve done our initial review and found the code is all in good shape from a licensing and compliance prospective. We’re working to get a CCLA in place. Maybe Aaron can give an update on that. Once we do, it’ll go to ESCo for an approval vote.

Aaron Williamson: I understand from DB that they hope to get the CCLA signed and code contributed by the end of September.

Leslie Spiro: Anything from LLC on whether they intend to include Plexus in future releases?

Lawrence Miller: That’s certainly the intention, it’s just a question of timing.

Aaron Williamson: I understand that one problem they’re looking for input on how to solve is the question of how to verify trust in apps outside the user’s corporate environment.

Leslie Spiro: They’re interested in using the Symphony token to mediate that interaction. So I thought that was kind of interested as well. I have a suggestion about the frequency of meetings, which is that we move to monthly meetings until things pick up a bit more. Do people have views on that?

Lawrence Miller: I think we should get the DB team at the meeting to discuss that. I think it’s an important discussion to have with this group, plus DB.

Leslie Spiro: I can’t make the next meeting, but should we put that on the agenda?

Aaron Williamson: I’m happy to facilitate in your absence.

Agenda

Attendees