Table of Contents

Date

Jul 12, 2017

Actions items from previous meetings

Meeting notes

Open Actions.

1^st two (ODP info and arrange Plexus meetings) assigned to @Aaron Williamson were skipped. The next two (Documentation and Symphony 1.46) were assigned to @Lynn Neir (Deactivated), possibly as a result of requests from Nick. Nick said he had started implementing the code to support the Symphony HTML 5 app (i.e. the frontend/UI) in OpenFin. Lynn said the code in the SSF repo was preliminary and subject to change as development of the UI progressed.

@Former user (Deleted) asked Lynn if/when/how there would be a pre-release version of the UI for people to test in other containers. Mazy Dar also asked Lynn if there were time scales for the UI release. Lynn said he did not have any. He said the first step is an internal ‘trial run’ of the UI and this has not started. Mazy asked if the pre-release UI could be made available via the SSF Pod so that Vendors could test against it pre-release.

Members discussed practical issues about how changes to the API and the UI can be communicated to ‘interested parties’ so they can prepare for changes and ensure support in their container. Lynn said he would present a proposal about if and how this info could be made available. Lynn said that this would become easier if the UI code was open-sourced, and that he believed that was the plan, but there were some blockers and also they wanted to redesign some stuff before open-sourcing.

 Members discussed the deployment model for the UI and Lynn confirmed that the LLC would release some kind of desktop installer that installs Electron and suitable pre-load scripts that connect to a URL in the client’s POD to load and run the UI.

Mazy asked Lynn for dates on the Symphony releases 1.47 and 1.48.

Lynn was asked to confirm that other containers would be able to run the UI in the same way, namely having the API implementation and then launch against the relevant URL which he confirmed. Lynn was then asked to get an official statement of the LLC position of the UI running in ‘other containers’ and how it would be supported.

 Leslie asked whether members were interested in DB’s Plexus contribution and said that Tick42 were. Discussion of the remaining Container.JS actions were postponed until the Container.JS agenda item arose.

 Draft Charter.

 Leslie read each of the four points in the draft charter and asked for comments.

 “1. The group will seek to define and standardize APIs required to integrate the Symphony HTML5 application into a desktop container, with a specific goal such that the application can be hosted in different desktop wrappers (aka desktop containers).”

@Johan Sandersson asked if this point should include language directed at confirming that the LLC supported their UI running in other containers that correctly implemented the agreed desktop API. Members expressed uncertainty about how that might work and more fundamentally whether the WG should take a position on LLC development/release plans.

“2. The group will seek to define and standardize APIs to enable any HTML5 application to run in a compatible desktop wrapper and take advantage of the standardized desktop integration features.”

This point generated the most feedback. Mazy asked if anyone was using Container.JS or planning to use it. He was concerned that discussing this in the WG would waste people’s time if no one was using it. Nick thought discussing this and DB’s Plexus contribution was a mistake because there was a lot of work required to support the first and primary objective. Leslie said he thought there was not a lot of work required—that the APIs had been reviewed and he thought that Colin had implemented a shim between the Symphony API and the proposed more general API within Container.JS (but that this is not confirmed).

 “3. Enable and expand the capabilities of the Symphony Desktop Container project(s) by direct contributions from the Foundation members and collaboration with Symphony LLC, in order to influence the direction of the project to meet the requirements of the Foundation members.”

Mazy asked if this was valid, and suggested that the process should be that the LLC defined the API for point 1, the WG reviewed it, and interested parties produced their own implementation. Mazy asked if anyone else had contributed to the API. Leslie said he thought that @Former user (Deleted) may have made contributions to the project and if not had reviewed and given feedback on the project.

 “4. The group will seek to influence and standardize the integration APIs used to both interact with the Symphony Desktop application and for more general desktop application interoperability. This influence will happen through working with Symphony LLC and direct contributions from the Foundation members”

Mark Hu said he thought Interop was a very important and useful area. @Former user (Deleted) asked if DB were planning on including the message types for interop for example message definitions. Leslie said that @Former user (Deleted)’s powerpoint contained a detailed description of which bits were planned for inclusion, but that when Leslie had asked Slava about including type definitions he was told this had not been decided. This also has relevance to the OpenML specification.

Nick and Mazy thought this was a very big area and should be in a separate WG. Leslie said that this had been discussed and could be reviewed when DB make a decision about whether they are releasing Plexus and whether it will be included with the UI, and that in the meantime it was a valid discussion point, and that an Interop API definition that could work with multiple Interop buses was currently part of Container.JS specification.

 @Gareth Davies said that it was important to keep a tight focus on the work covered by the WG and to focus on deliverables, which might indicate dropping this.

Leslie proposed moving any decisions on charter revisions to a later meeting, ideally one that Aaron and James could attend.

Action items

Agenda

Attendees