Table of Contents

Date

14 Dec 2016

Attendees

Actions items from previous meetings

• Rob Koyfman: send Github repo identifiers to Former user (Deleted), so that he can take the internal CS legal steps
• Rob Koyfman: work internally with LLC engineers to determine where and why the Symphony app is circumventing the app-bridge API, and update the group
• Rob Koyfman: identify appropriate LLC engineers to attend future WG meetings, and let Former user (Deleted) and Peter Monks know (so they can be invited, added to the ML, etc.)
• Former user (Deleted) to generate docs from CS shim, and send to Former user (Deleted)
• Former user (Deleted): schedule meeting with JC and Matthew Gardner to discuss WG ↔ LLC engagement model

Agenda

Meeting notes

• Update on call with JC
  
  • James: Followup conversation on "how the DW WG charter looks at the end of the year and how any action we want to take going forward would work with our colleagues in Symphony LLC".  Quick update JC?
  • JC: current status is that the current code for the PoC is in the Foundation and open to anyone to view and propose modifications etc.  It's very basic for sure.  In terms of a reflection of what I've heard so far, and update on what would be useful for LLC: I'm working on dedicated staffing for this initiative, beyond the POC.  I expect a team of around 4 dedicated in the new year.  Explicit goals are to:
    • Improve performance and development agility - ability to innovate and rapidly improve or enhance functionality of the wrapper vs the Minuet code, which is fairly cumbersome.
    • Build a path to support our customers' other wrappers, and how this plays into that is how hopefully by standardisation of the JS to native interfaces, standardising the app-to-app interfaces (the "embedding API in Minuet") and provide the community with a free reference implementation to play with, extend, and create derivative works.  That's the charter of this project, from the LLC side.
  • Amit: is there a timeline?
    • JC: we're just modifying the POC and starting to add back-parity features.  In the New Year we'll begin dedicating staff and conduct a formal kickoff of the concerted effort to get it to parity and beyond.
    • Amit: what is the cutoff point to the new container?
    • JC: my desire is feature parity and shippable product in Q2.  Q1 would be development & community engagement & requirements gathering.  It would be awesome to augment those 4 LLC staff with folks from the community.
  • James: now this container is contributed, what do you see the role of the WG in helping shape the direction and governance around that?
    • JC: I need to be participating, but by no means want to define the charter - that's up to the governance of the WG.  But my hope would be that if we can choose the right set of technologies and we can create this reference implementation, then this would serve as the basis for some form of standardisation of the JS → native interfaces and the app → app interface, so that to the extent that partners build their own apps or buy from 3rd parties, it's easy to get to feature parity with what we ship as the supported wrapper for Symphony.
    • James: so practically, how do we help shape what a lot of people on the WG have expressed interest in, which is helping to standardise the JS → native interface in particular, so they can leverage their own containers?  What's the most practical way for us to be able to do that?
    • JC: we need to get a technical project lead identified on our side for the OSS repository, and like the IETF process, work with rough consensus and working code.  The reference implementation being the foundation & documentation of the interfaces we put in there and should be the foundation of interoperability.  And that form of building and defining the interfaces should be collaborative - anyone can see it, participate, comment, make suggestions, contribute code, etc.
    • James: question to those with your own internal containers and want to run Symphony within them - does this sound like a positive move forward?  There'll be a de-facto interface that we can comment on etc. - is that a good working model?
    • Dov: it seems to be - that could be fine.
    • JC: for pre-existing implementations some sort of shim layer would be necessary but at least those APIs could be well defined, by working code.
    • James: I think anybody who has something already, is absolutely going to have to write a shim, and presumably that party would take on the responsibility of writing that shim.
    • Dov: so to summarise, there will be an interface layer that anyone could shim against?  And this group would define the interface?
    • JC: by having the reference implementation in open source, it becomes the guide to shim up against.
    • Dov: so we should pull it down and have a play.
    • James: from the WG perspective we'd want to say something stronger, and define the interface explicitly and put it under version control etc.  It's not very good for other parties delivering containers if the reference implementation can change at any point.  At some point we'd want to declare the interface.
    • JC: yes and version it and so on - that makes perfect sense.
    • James: getting to a point, through active contribution, that we're at "v1.0" of the Symphony JS API
    • JC: that would be great.
    • Peter: and the code is there in the open and builds
    • James: right, but there's not much code there - it's all native Electron
    • John De Murga: I've taken a look and was a bit bemused by it.
    • James: request for LLC is that we want some more readme style pointers "if you implemented this interface then in theory Symphony would run with all the features against your own container"
    • JC: the difference between raw Electron and the POC is to get the Symphony webapp to run in the container, integrate with SSO, open links in the default browser, etc.
    • John De Murga: are we sure that everything has been pushed out to the open source repo?
    • Peter: yes - we used Github to transfer the repository, so the entire commit history is there
    • John De Murga: then I must be missing something because there isn't much there
    • Peter: right.  Keep me honest JC, but this is mostly just configuration changes to make the Symphony webapp work well inside Electron - Minuet parity features are coming later.
    • JC: correct.  Right now it's just configuration - pod URLs need to be tweaked per build, etc. but we're moving to pod-less login soon.
    • James: it would be good to know your milestone points
    • JC: right - we're not advanced enough yet as the project isn't staffed yet
    • James: I guess January we'd start with that.  Any questions form the group?  This seems like a concrete starting point and once the team is staffed we'll be able to make progress.  Also some admin changes for me to change our charter to reflect this, then come back to the group for details on how to order things.  But any other questions for JC?
    • <none>
• Charter discussion:
  
  • James: the way the charter is setup at the moment it's talking about Minuet and there's a question about whether that should stay in the charter.  JC - is the locked in plan for Symphony to move away from Minuet?
  • JC: yes some tweaks and performance improvements, but that's in lieu of choosing the next technology
  • James: so we need to formally decide whether we should drop the Minuet charter item.  The second charter item is around standardisation of the JS → native interface and we're still talking about that, albeit in a more concrete way.  So I would say that I need to look at the language, but at most adjustments will be required.  Then we need to decide amongst ourselves what our relationship with the SymphonyElectron project is - whether it's part of the WG or separate governance.  We've talked about splitting the sort of things the Foundation looks after into projects and working groups, where WGs are more interested in standards and project more interested in software.
  • Peter: the updated wiki content, especially around projects, is worth reviewing.
  • James: seems like they're going to be closely related here, and we may have project and working group in the same space in this case.  Any comments on that or do we want to wait for a more concrete proposal?  Does anybody having any interest in continuing with the charter item around Minuet?
  • Amit: no point in going forward with Minuet in this case
  • Dov: agreed
  • James: should the group remain involved in standard setting and the project, or should there be a sub-group?
  • Dov: I think 2 calls will be a big ask, and the group is going to be a subset anyway.
  • <general agreement>
  • James: ok that gives me an idea, and I'll send out some ideas for the group to review.
  • Dov: things will also change once there's code flowing.  There'll be more to talk about.
  • James: agree 100%.  Developing the standard via code means they're joined at the hip.  Not a huge amount of value in splitting it in a formal manner.
• AOB:
  • We will pick up again in the New Year.
  • Please check that you have the invite for next year.  I'll probably send out a refreshed invite in the New Year.
  • Thank you for your participation throughout the year!

Action items

• Former user (Deleted) to review charter items, with an eye to removing the Minuet objective and tweaking the standardisation objective if needed
• Former user (Deleted) to setup a 2017 meeting schedule
  
  • Peter Monks to offer the Foundation's Webex for the fortnightly calls