Table of Contents

Date

16 Nov 2016

Attendees

Actions items from previous meetings

• Rob Koyfman to 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) to clear any IP hurdles then share with this WG
• Gareth Davies, Former user (Deleted), Matthew Gardner: organise to meet in person in London on Tuesday November 15th, to start identifying container APIs require by Symphony app (via app-bridge JS)
• All: send questions you'd like JC to answer next meeting to Former user (Deleted) and/or Peter Monks

Agenda

Meeting notes

• Roll call
• Action items:
  • James: Rob isn't present, and I don't believe anything has been done on his actions.
  • James: I've completed my sub-task (new contribution agreement), John is now able to generate and share the docs.
  • Matthew: Gareth, Nick and I met, and I wrote up the details on this wiki page.
• Introduce new members:
  • Tick42 / Leslie Spiro: particular interest is in a product of ours called GLUE, which allows apps to talk to each other (app to web, etc.).  We'd like to enable Symphony to chat with other applications.
  • Colin Eberhardt: Foundation's first at-large member.  Technology Director at ScottLogic, consulting company within the financial domain.  Lots of HTML5 and desktop container experience.
• Symphony container plan update, from Jonathan Christensen (JC):
  • Slide 1:
  • 
  • We are actively building a PoC based on standard, off-the-shelf Electron.  We have a git repository up and running.  I'm using this wrapper for my own Symphony experience.
  • Tim: it would be good to get access to the git repository.
  • Leslie: I'm interested in your use cases as much as anything else.  Is the primary interest in shipping the Symphony web experience as a desktop app?
    • JC: that's covered in the next three slides.
  • Slide 2:
  • 
  • JC: The Confluence page we were looking at earlier has many of the subtle extension points needed for this e.g. popping the window to the top, or for richer or more persistent notifications.  This is the primary motivation for us.
  • Slide 3:
  • 
  • JC: Some of the hooks here are standard, some of them are proprietary and will vary by provider.  Electron hasn't been focused on this - most of the apps built on Electron today have been consumer oriented apps and this hasn't been a priority for them.
  • Colin: would you consider these to be natural extensions to Electron, or architectural changes to Electron / fundamental changes to the current architecture?
    • JC: I don't know yet.  There's some indication that it's a mix of both things.  For example the security model may need significant enhancements - would that be an extension or contributed upstream?  Electron seem to be happy with their current security model, so it's a bit of an open question.
    • Colin: so security might be significant, but the others e.g. group policy controls extension less so?
    • JC: yes.
    • Nick: we've had experience with these issues.  For example are you thinking of using CEF for group policies?
    • JC: to be clear we haven't had requests for these features yet.  We think they're likely to come, but it's not an area we've invested in or identified a plan to tackle them.
  • Slide 4:
  • 
  • JC: this use case is about providing hooks between applications on the desktop.  Examples might be how users hook complex Excel spreadsheet with other apps that act as data sources to those models.  A simple example might be sharing presence across multiple applications and do that locally on the desktop - what sort of interfaces would be built at that layer.  Again this is a use case we haven't explored or thought about what the APIs would look like.  Today Symphony's APIs are cloud based and more oriented to the web development model
  • Leslie: use case 3 is what our business is based on, so this is certainly something we have views on, and happy to talk about some of the use cases we see.
  • JC: there's a desktop API with the Paragon product, and there are apps that are built to that API and currently sharing data through those interfaces with Symphony.  We don't know how many.
  • Leslie: one of the areas we're interested in is "on behalf of", but it seems like an application bus would be a way to get around those current limitations.  Do you see those things as related or ...?
  • JC: absolutely. Today at the point of development with the POC, we're scoping use case #1 (native).  We haven't delved into the approach for the other 2 use cases.  Our current API is cloud based and allows a lot of this, but it's a very different model.  In terms of current progress, we have builds up and running.  Phase 1 of the POC is complete - Symphony is building and running on the Electron wrapper, and we're using that today in our corporate environment.  Next steps are to look at Paragon implementation and identify gaps like specialised notifications, saved layout, and a bunch of things that are in Paragon today and that we would need for feature parity.  That's a fairly big list - quite a few work items.  The Confluence page calls out quite a few of the APIs that would be needed to implement these features.  Some of them are complete because they're out-of-the-box with Electron.
  • James: a key question from our point of view is that the LLC seems to be doing some of the work that would be part of the standardisation effort as part of porting Symphony to Electron.  We'd want to be hooked into that, and potentially put requirements into the concrete API between Symphony-the-app and its desktop wrapper.  That would seem to be a good outcome for everyone.  It sounds like you're doing the work we were hoping to do de-facto within the working group.
  • JC: what we've done so far is get a build of the wrapper that points to our corporate pod and hosts the web application.  We immediately found some obvious bugs e.g. if you click on a link, it'll open a new electron window instead of the browser, by default.  A number of small configuration items are also needed (e.g. notifications) that would bring us to parity with Paragon.  Certainly it would be good to identify those in terms of "APIs" that would be necessary to support those features.  Or only goal right now is basic feasibility & gap analysis between the current wrapper and Electron, and it's a fairly sizable list to create that feature parity required / demanded by customers.
  • Colin: it sounds like you're proposing a standardised API for HTML5 containers - I'd wonder about the value of that.  Do people really want to switch out containers?  A more useful thing might be to standardise the communication between containers and applications.
  • James: briefly to answer that, in the lifetime of this WG it's come out that many financial orgs have their own container, with an entire ecosystem around it, and they'd prefer not to be using the Symphony container but instead their own.  To do that, they need the Symphony application to abide by a standard, so they can drop it in their own container.
  • Colin: yes we've used quite a few of them.  So the idea is to have a standard that allows banks to drop their own containers for Symphony's?
  • Leslie: isn't it to run the Symphony app in any bank's container?
  • James: this working group had two goals originally. One is to take the desktop wrapper that was donated to the Foundation (Paragon / Minuet) and manage that as a separate entity.  The other was to standardise the interface to allow Symphony to run in any container - Minuet, Electron, OpenFin, whatever you like.  It's become clear that we are struggling to get the Paragon  / Minuet code contributed in its current form, and what JC tells us is that the LLC is moving away from that wrapper technology anyway, so there's an open question for the Foundation around what to do with the code once it's contributed.
  • JC: it's very much an open question about the level of the API, where the group should focus.  Is it down towards use case 3, or is it the very basic wrapper interface to the JS code.  I don't know the answer to that question.  What I do know is that we need to ship a complete solution to most of our customers that's complete, feature rich, and just works.  Our strategy for delivering that thus far has been Minuet, and going forward is likely to be Electron.
  • Colin: if you look externally there's a much greater success for creating standards for communication between applications (things like RSS, XML, etc.).  Standardised APIs that are abstractions on top of implementations of the same thing are fairly rare (e.g. JPA).
  • James: the counter to that argument are the W3C standards.
  • Nick: I was going to say that.  What we're thinking of in this working group is something closer to W3C standards, where browsers are replaced with containers.  I agree that it would be very valuable to look at standard objects for communication.  Some of that may be is more in the scope of the Financial Objects Working Group however.
  • Colin: I see your point.  W3C is a good counter example.
  • James: there is another Working Group called the "Financial Object Standardisation Working Group" that talks about some of the protocol things you're talking about.  Primarily that's about messages within Symphony, but potentially that could extend out to interop between apps
  • Nick: that group has been focused exclusively on passing those objects within Symphony workflows, and not out to other apps.
  • James: we've talked about interop as one of the suites of APIs we want to talk about.  But we want to talk about the concrete interface between Symphony and its container.
  • Rajesh: why aren't we sticking to web standards for this?
  • JC: examples of things that aren't in web standards, nor out-of-the-box features of Electron: toast notifications that can be selectively positioned on the screen; a task bar that blinks for urgent notifications; screen captures native to the app; screen sharing and how it's reflected in the UI; the ability to make pop outs and have multiple persisted window layouts; doing titles within those pop out windows.  It's low level stuff, but it's all part of the application and its behaviour.  An open question is whether these are useful things to standardise and extend Electron with?
  • Colin: do you consider the current Electron APIs to be the baseline?  So if OpenFin was to become one of the standardised containers, they'd have to expose both Electron APIs and standard APIs?
  • JC: an example is open link in default browser is something that's a one line configuration in Electron.  Copy & paste is a native capability of Electron, but needs to be turned on.  If the intent is to have multiple container implementations across the customer base, and work consistently and reliably, then there'd need to be a standard.
  • James: we've talked about this previously, but haven't come to a baseline  The thinking is that it should be W3C based, but we had not anointed Electron as the baseline API.  We could obviously change our mind on that, especially given the LLC's decision.
  • JC: going back to the simple example of open link in browser. It's available, implemented a specific way in Electron.  I don't know if there's a more globally standard way of doing that.
  • James: if we agreed that the standard API for that was called "bob" and Symphony called "bob", then Electron or OpenFin or whatever would just implement "bob", perhaps as a shim.  And if there were a W3c standard for this, then we'd propose that.
  • JC: agreed.
  • Nick : I'd be interested to look at phase 2 & 3 standards  Phase 1 is low hanging fruit and it's pretty easy to see how those APIs would work, and plenty of examples of them working in the wild today.  How we standardise around things like group policy, web deployment, security, interop message bus stuff  - that's where the proof is in the pudding.
  • Colin: from an OpenFin perspective, your basic API (e.g. building menus) is quite different from Electron.  Would you suggest we adopt Electron as a baseline or OpenFin as a baseline?  Both would have to be shimmed.
  • Nick: I really think there may not be a right API across the board yet.  I don't think what OpenFin has done re programmatic APIs is necessarily the best.  There's lot of things (like menus) that are very interesting.  OpenFin takes a very different position than Electron on how that's handled.  I don't think either is better than the other - it's a matter of opinion.  Electron is focused on being an analog to native apps and uses system menus.  OpenFin is informed from a web opinion, and takes the opinion that web approaches (HTML & CSS) are the right way to build menus.
  • Colin: isn't that a Windows opinion?
  • Nick: you could take that point of view on the history.  I can't comment on the history, but there's definitely the way applications are built on web vs built natively - on the web you want to control as much of the look-and-feel as possible, rather than leaving it to system stuff.  I think there's arguments either way and maybe both models should be supported.  I don't have enough of an opinion about it right ow, but I think that's an interesting point of conversation with standards.  Our focus on Electron has been on making things like security, group policies work.
  • James: given the LLC's work, do we still feel there's value on looking at current de-facto API?  We probably want a chunk of time in the next meeting to discuss this further.  JC are you building this externally, on a public Github?
  • JC: AFAICT the work has all been done in the "symphonyOSF" Github organisation (which is private).
  • James: I thought this was being developed in the open.  Is there any intention around that, or was I mistaken?
  • JC: no intention not to do that.  Mirroring the repo would be trivial, but we have to figure out what that means.  We'll take that as an action on our side.
  • Peter: please include me in that, as I've been privy to conversations with Lawrence Miller on this topic.
  • James: let's set up a session next time to continue to review the document that Matthew, Nick & Gareth put together, and expand that out and get some suggestions on where the APIs are.  Those who are new, if there are any questions on how the group operates, etc. I'm happy to setup a sidebar to go over that.
• AOB:
  
  • <none>

Action items

• 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)