...

Actions items from previous meetings

•  Rob Koyfman to send : 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)
•  Matthew Gardner, Gareth Davies, Former user (Deleted): flesh out the Symphony Wrapper Current API Analysis wiki page, including new columns as appropriate
  
  •  Peter Monks: schedule discussion on the revised content for next meeting
  •  All: review the revised text ahead of next meeting
•  Jonathan Christensen: internally evaluate the opportunity to open source the Electron POC (including Lawrence Miller (Deactivated) and Peter Monks in the discussion)

...

Meeting notes

• Peter: 

  Jira Legacy
  server JIRA (symphonyoss.atlassian.net) columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 1a238f36-abc1-369b-9e20-eb8cf05423c5 key CONTRIB-29

   (LLC Electron PoC) update:
  
  • Following last meeting, JC quickly ran it through internal LLC approval, and then ESCo voted to approve the contribution.  The code transfer is held up on some legal minutiae (i.e. missing LICENSE file), but that's the only thing preventing it from being open sourced.  Should we invite LLC engineers to this WG?
  • Leslie: say it's in the open and has the license thing.  If we take the code and build it, will it be able to connect into Symphony, or will there be private stuff needed (keys etc.)?  Will people be able to create their own custom desktop experience?
  • James: from what I understand, I think the answer is yes, but probably more by accident rather than intent.  My understanding is that the client uses the internet facing Symphony code,.  But we haven't had a technical deep-dive yet.
  • Leslie: we have a particular interest in extending "on behalf of" and this might be an alternative to waiting for Symphony to implement that piece
  • James: once we have the code we'll be able to work this out. One useful thing we could do is invite the lead to answer these questions.
  • Nick: I missed the start of the meeting, but is there a timeline for this?
  • James: no - but the internal sign-offs have been done, and the ESCo has approved it.  We're just waiting for the LICENSE to be added to their repo so they can move it across.  It doesn't sound hard, but I'd hate to put timelines on it, given the experience with Minuet...    We're not waiting for any legal sign-offs, which is a good thing.
  • Colin: sounds like a positive step.  It'd be good to understand what their motivations and roadmap are, when they make it public.
  • James: in the last meeting we got some of that.  We can continue asking the LLC to share their strategy around desktop wrappers.
• James: APIs / de-facto interface between Symphony app and container:
  • Something that's been in the background for a while, is that we probably need to think about formally adjusting the charter for this WG.  I would recommend everyone goes back and has a read of it.  It's a two part charter - 1. Minuet 2. standardising interactions between desktop containers and apps (Symphony).  If it feels like Electron is the concrete direction for the LLC, then the API that they're coding against is the Electron API, and as a group we have to decide if we're happy with that and whether those members who are keen to understand the API so they can run Symphony in their own containers would be be satisfied with the API effectively being the Electron API, and if you want to run Symphony in your own container the shim would be Electron-based.  Or we could push for something more standards based.  Right now we don't know what the LLC's thoughts here are, but it seems like the LLC's preference is Electron.
  • Matthew: to push it to a smaller piece of work we were trying to merge 3 different things: Symphony API, W3C APIs, Electron APIs.  If LLC wants to go to Electron I see no reason not to go with it, but we need them to stick with it, so we can all work towards it.  A positive step, but we need that clarity that they're committing to that API.  I think it's also important that the Symphony client should work more natively within Chrome, Firefox, Edge to support DR purposes.  There are times where we can't download a client.
  • James: it does run in Chrome.
  • Matthew: sure, but you don't get notifications.  That's fine in some cases, but not in this context.  And we know Chrome and Firefox do support this because we see it in webapps like Facebook Messenger.  Really this is where the LLC should be going.
  • James: agreed.  We'll need to extract that from the meeting minutes and send to LLC product team.
  • James: do we want to continue focusing on Minuet, or standardising on Electron (which may not be palatable for some people), or documenting what the LLC is doing?
  • Gareth: we need to find out what's the surface area of Symphony that's hitting APIs.  There is no notification API in Electron, for example.  I'd much prefer to see a list of features it needs, then have a yes/no for each.
  • James: we've done that, on the Confluence site.
  • Matthew: we spent a lot of time on it, but I don't want it to be thrown away.  Until we know what the LLC is doing we risk wasting time.  I'd suggest we put that on ice.
  • Gareth: if they're pivoting containers how are they going to handle backwards compatibility etc.?  If they're rolling forward we'd want to see the proposals for those designs pitched to this group rather than just developed in isolation.  If people have different containers then we'd want to provide that feedback up front.
  • James: it's an interesting point.  At ESCo, one of the principles we've been developing is that WGs shouldn't rely on LLC doing what they need to achieve their goals, and we're back into that now.  LLC has shown over time that they won't necessarily play along - they're not the same entity as the Foundation.  Our lever for influencing is via the LLC board, not Foundation constructs.  So yes we can say we want them to develop in the open and have influence, and open APIs and feature sets, and that's certainly something we can do, but whether they pay attention to it or not is another matter.  As the Foundation we can only influence code that's in the Foundation directly.  Once the Electron POC is in the Foundation we can have slightly more input.
  • Leslie: they've also got working code - there's no point reviewing the designs when there's working code.  If it's not going to be suitable for the various needs people have...
  • Nick: I'm not clear on what the needs are that people have.  Is there a need to run Symphony in whatever container's in use?  Is there a need to run in a standard browser, which begs the questions of having a standard API (and Electron APIs can't be added to a standard browser)?  Beyond that what are the needs?
  • James: other containers.  The idea is that we have standard APIs so that Symphony can run in any container - OpenFin, Electron, Morgan Stanley container, JP Morgan container, Minuet, etc.  Via some mechanism you could install Symphony + your container and leverage those capabilities if they exist.
  • Nick: so it's a standard API that could go to Electron, a browser, OpenFin, or anything else, as long as the person on the other end of the container is willing to write a shim to that standard interface.  But if the LLC isn't interested in using that standard API, I'm not clear on the role of the WG.
  • James: I agree Nick, and that's exactly my point.  If we're a WG trying to influence an organisation that doesn't want to be influenced, then we should stop the WG and try to figure out how else to influence them.
  • Gareth: I can't disagree with that at all.
  • Matthew: to be massively controversial: are any firms planning on using this new Electron wrapper?
  • James: speaking as Credit Suisse we're using Minuet and if it switched to Electron, we'd use that.  We treat Symphony as a full application with its own install.
  • Leslie: perhaps the question is: "if Symphony give you a desktop wrapper as part of their app, would you use it?"
  • Matthew: I'm interested to hear - Minuet is battle tested and now they're switching to Electron, and it's possible we're entering a VHS vs Betamax battle.
  • James: for the customers it's more about how do you treat Symphony?  Win32 install or as an HTML5 app that you want to put into your own HTML5 app store, to be delivered to your own container?  I'm sure there are many who've taken the simple option of the Win32 installer.  If I were Symphony I'd just switch the container under the covers and customers wouldn't have a choice.
  • Leslie: this is related to whether I can take a build and compile and use it on a production Symphony pod, or whether I need a special certificate to use it.
  • James: remember we're just talking about the container, not the application.
  •  Leslie: does the app run on the client or on a server?
  • James: depends if you're running in a container or a browser.  Either way it downloads the JS at runtime.
  • Gareth: a container is just like running a browser - behind the scenes it's caching assets etc.  It's not a fat client - it's like a browser++ with more integration with the desktop.  It's not a packaged app - the App code is still hosted by Symphony.  There's a small bootstrapping package in Minuet and they may do that with the new Electron code too - I don't know.
  • James: and a small crypto package?
  • Gareth: yes.  But the app itself is remote and outside your firewall.
  • Nick: have they said anything about the native crypto piece?  If they do it in node then it's going to involve plain text files on the desktop.
  • James: whatever they do is done in JS for the internet-facing webapp anyway.
  • Nick: but if they're encrypting & decrypting in the client in JS, then the same problem exists.
  • Gareth: this would be a great question for the LLC guys.  On the Minuet side there's a DLL that runs the encryption, and somehow it falls back gracefully in the browser.
  • James: I was under the impression it was done in the browser.
  • Nick: there are JS libraries that do encryption, but it's meaningless to run them inside a browser.
  • James: you've just blown up the Symphony business case.  
  • Gareth: it would be good for everyone to understand what's being done around security, sandboxes etc. - we're all aware of the shortcomings of Electron and doing this in the open will be key to getting those decisions out there is key.  If I was being asked to download an installer from outside the firewall I'd want to understand it's a well understood solution that's gone through the usual tech risk cycles.
  • James: interesting questions but is that within the remit of this WG?
  • Nick: I agree James - I'm not sure, but it's at the heart of the whole proposition of Symphony.  There's also interoperability within this app store model, which is of interest to me having worked on Eikon and looking at web/hybrid architectures for quite some time.  Once they put 3rd party code in there they're opening up a very large vector.
  • Gareth: there is a role in terms of interoperability.  It comes back to the question of what is the point of this group.  If LLC won't play ball, then what's the point.  But I think they understand that interoperability is a priority.
  • James: that has been the case in the past.  But if attendance is participation we don't regularly get attendance from LLC.  And we're definitely not getting it from a level that would let us influence strategy.
  • Gareth: JC is doing a lot of this work and he seems to be keen to participate in the group.  I think he's a must-have for these sessions so we can make that bridge.  There's no point in making these decisions without their participation, given they're custodian of the platform.  Why don't we invite JC to attend the meetings?
  • James: I'll have an offline conversation with him to understand what's going on.  To be brutally honest I'm a little fed up running this WG and feeling like we're not getting far.  I want to be able to execute on something or stop the WG.  Anyone who wants to join me discussing this with JC would be welcome. 
  • Matthew: I'd like to join that call.
• AOB:
  • James: Holiday season:
    • I'm out the week of the 28th and will cancel that meeting.
    • Depending where we get to with JC, I'll email around regarding the Jan 14th meeting.

Action items

•  Former user (Deleted): schedule meeting with JC and Matthew Gardner