Table of Contents

Date

22 Mar 2017

Attendees

Actions items from previous meetings

• Colin Eberhardt (He/Him): prepare demo of notification api implementation for next meeting
• Specification subgroup (Former user (Deleted), Lynn Neir (Deactivated), Colin Eberhardt (He/Him), etc.) will meet every Friday to continue defining example specifications
• Former user (Deleted): revise draft charter item 3 to focus WG's interoperability mission to desktop interop only; bring charter to a vote.
• Former user (Deleted): work internally at DB to ready interbank interop project for presentation to WG
• Jonathan Christensen: add the existing Symphony Electron container backlog & roadmap to the WG Github project.

Agenda

Meeting notes

• Convene
• Action item review
• API implementation demo:
  • Colin: to briefly recap what we're doing: I've got a couple of people at ScottLogic working on this part time.  We have a roadmap on the wiki, and we're going broad first - exploring a number of key APIs: notifications, window opening, screen capture and a bit on inter-window messaging & application lifecycle.  The idea in each of these areas is to throw together a quick PoC on OpenFin and Electron and, where possible, a little behaviour in the browser.  The focus is on finding out what's technically possible and where the technical challenges are.  Once we've touched on all the key functional areas, we'd like to loop back and elaborate on those APIs.
  • Demo:
    • Electron:
      • 
      • 
    • OpenFin:
      • 
    • All of the HTML & JS in the application is identical between containers.
    • New Window API (OpenFin):
      • 
  • We haven't thought much about naming or parameters, but Brian has provided some great information on this and we'd like to use that information in the future.  For inter-window messaging there's a PR up there that's currently in review and hopefully that's something we'll add soon.  We've got a little bit of application lifecycle to allow the same code to run in each container.  In the near future we'll look at a very simple manifest, so they have exactly the same entry point.  In terms of breadth I think we're close to ticking off some of the most interesting / important APIs, then we'll loop back and go into detail.  Any questions?
  • Matt: what you've done here is a shim between the two?  I recognise some of this from the Electron samples, but what's the work you did?
  • Colin: so taking the example of the window API - we defined an API that allows new windows to be opened.  So rather than using an existing API and shimming it between the containers, we've implemented a new API that our sample app code uses, and shimmed it for each container.  The demo app on GitHub has all of this code, and it's all running against our new Symphony Desktop API, and will run in both containers.  We've then got 3 shim layers - api-openfin, api-electron, and api-browser.  Then the dependencies control which API implementation to pull in.
  • Matt: so pulling in the right API is all taken care of.
  • Colin: yes - the goal is the exact same code in all three contexts - OpenFin, Electron, browser, and perhaps adapted to others - Minuet, Paragon, etc. - too.  Every demo here uses the "ssf" classes.  In the near future I'd like to take some good example Electron apps, and have them target the "Symphony Desktop APIs", so they work on OpenFin and Electron.  The Symphony messaging application should be able to target these APIs too, and therefore run on each container.  I could show you the dirty shim work that's involved - there were some technical things we're exploring there - e.g. OpenFin doesn't have preload scripts.  The entry point into the application in OpenFin is a hidden window, like Electron where the main process isn't associated with a renderer - we're doing all the work to normalise those.
  • Mazy: this is great.  I think you alluded to it, but is the idea that there would be some kind of mechanism for the app to know what it's running in?  So that every time it makes a call to the Symphony API it's delegated to the correct implementation & engine?
  • Colin: good question and this needs further debate.  There's a fundamental difference between the way we've approached it and how Brian's approached it.  Brian has written it such that the shim code is within the application, whereas we've targeted it that the shim is in the container, and so the application doesn't include it.  There are pros and cons to each.
  • Nick: we discussed this quite a bit in the beginning, and punted on it to focus instead on the specific APIs themselves.  I'm not sure where we want to go with that at this point, but it would be interesting to get back to that.  I think the work Colin's done here is terrific and proves out the basic mechanisms - it's quite easy to achieve this kind of parity via this kind of API, and going forward we need to decide where do we go from here.  Do we just begin to build out the existing pattern we have so far and punt on the larger issues, or do we focus on the bigger issues first?
  • Colin: I like the approach where the shim code is carried with the app, but there are inherent limitations to that.  If it's possible to shim something in your JS app code then it's great, but if it's not possible then you're in trouble.  A good concrete example of this is screen snippets - right now you can only capture the current window, but Symphony wants to capture the desktop.  That's not possible in OpenFin or Electron - it needs platform level code - and therefore wouldn't be possible if the shim is inside the app.
  • Leslie: clearly at one level you can't do what you can't do.  But there are two issues:
    1. is it worth having a capabilities API eg. "can I capture the full desktop?" that the application can adjust to?
    2. the second is that if I'm developing in a bank I may want a single URL that's auto-detecting, and so if a firm is committed to OpenFin then that's all I need to target - I don't need to worry about mixed environments.
    • Being able to enquire on the capabilities and have several levels - "open window" is mandatory, but "capture desktop" is optional, for example - is key.
  • Colin: yeah I think that's the right approach - we have to be influenced by how people will use this.  As I say for now we're ignoring that.  Next thing is app bootstrapping, which will allow pretty complicated apps against this API, and we can circle back to distribution.
  • Leslie: yes writing code is key to driving consensus.  What you're doing is really interesting and we are interested in working with you on it.  One thing is that calling it the "Symphony API" gives the wrong idea - this has nothing to do with messaging, which is what I think of when I hear "Symphony".
  • Colin: yeah we need to have a naming conversation - I liked Brian's idea of "desktop.js".    
  • Brian: or "core.io"  
  • Leslie: "ssf" doesn't have the same connotations, to be fair.
  • Colin: I think naming is important, but it's a bit premature.  I'm really keen to find out what it will take to get Symphony to use this API instead of building on top of Electron.  That way we get a real user for this, rather than dummy apps.
  • Nick: this is the big question.  Do we have anyone from the LLC on the call?
  • Peter: yes - Lawrence.
  • Colin: are you able to tackle that particular question?
  • Lawrence: there are a lot of iterations about us picking particular APIs or wrapper technologies, so I think it would be better for JC to comment on it rather than me opining on it.
  • Colin: I'd hope they'd be amenable to picking the technology chosen by the WG.
  • Lawrence: agree, I just can't comment on it.
  • Colin: I think there should be an action for that, so that we can find out what they need from us next.  Visibility on what's required - that would be great.
  • Mazy: in the work you just showed us, were you changing code in the Symphony front end, or is that wrapper code that you're able to do outside the front end Symphony code?
  • Colin: you mean the code that's currently on GitHub?
  • Mazy: I guess I don't know what I'm looking at exactly - the Symphony chat client is not part of what you've done?
  • Colin: that's correct - the name "Symphony" is there only because of the WG, not the front end code.
  • Mazy: so next step would be for the Symphony chat client to use that API and be able to run in multiple containers, right?
  • Colin: exactly.  We'd be happy to do that, but I'd be happier for someone on that development team to do that, so we can get a proper opinion and perspective on that API.
  • Mazy: that seems like the best next step, rather than asking Symphony for a commitment.
  • Colin: and even before that, taking a look at what we've done to date and look for gaps.
  • Laurence: I'll make sure to highlight this discussion to JC offline.
  • Colin: great.  If he wants to hook up outside the WG meetings and give me a call I'd be happy to have a chat.  Any more questions?   ...  Peter - any update on the contribution process (for this work)?
  • Peter: I apologise -
    Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    is stuck on us - I'll chase that up.
• API specification subgroup
  
  • Nick: this is one and the same as the previous conversation.
• Revised charter:
  • Peter: we'll punt this to next meeting because James isn't present.  A small related update is that ESCo are providing assistance to James on this, and I know that their work is not complete.
• Electron hiring update:
  • Peter: I checked in with JC this morning and he gave me this update: "No significant updates from my side except there are now regular builds and we are close to having cross platform notifications done.".  Question for the group: are you working with Lynn Neir (the lead LLC engineer on that project) on this notifications stuff?
  • Nick: yes, Lynn Neir is working with us on the notification API
  • Colin: within Electron we're using some open source notification functionality, so that we get coverage on Windows 7 - this is not the built-in Electron notification.  Long term goal is for notification to have quite a bit more functionality than the HTML5 API.
  • Nick: for me, if we're to go deep, if the Symphony team is to start working on this we'd have to start looking at the gaps between the HTML5 API.  On the OpenFin side we can close those gaps, we just have to know what the specifications are.
  • Colin: having this development driven is key.
  • Peter: I'm sorry if my question wasn't clear: are the LLC team working with you on the notifications API JC mentioned in his update?
  • Nick: they're not really working with us, but I don't really know what this means.
  • Colin: if you look at their repository they've just merged in a notification implementation.  But I'm not too worried about notifications, I'd rather focus on their broader requirements so that we can align ... actually looking at the PR, it looks tricky - it's a thousand lines of code with a reasonably wide range of functionality - flash, colour, show click close handlers, etc.  They've got a problem in that they need to develop this app and they're ahead of the WG.
  • Peter: yes.  That's exactly the kind of problem I'm hoping the WG can avoid by staying in front.

  • Colin: not sure I'd agree with that.  They've got projects they need to deliver - they can't be dependent on a volunteer group such as this WG.

  • Leslie: there's a third option which is for them to go "this has cross platform implications - can you as a WG comment on it?"  This is besides "can you provide it for us" (which is never going to happen).  For complex stuff they can at least understand that we have a review / sign-off function.
  • Laurence: we should have JC as part of this dialogue.
  • Colin: it feels like we should have a one-of special meeting for that purpose.
  • Peter: a call makes sense.  Keep in mind that one of the goals of this working group is to influence the LLC (original charter objective #2), and staying out in front of the LLC (so that it's easy for them to consume the standard APIs the group defines / implements) is an easier way to have that influence.
• AOB:
  • Peter: Foundation staff are in the middle of conference season, so we're juggling responsibilities.  I'll create the blank placeholder page for next meeting, but please update it with agenda topics you'd like to discuss!  That helps us to help you have effective meetings.

Action items

• Lawrence Miller (Deactivated): talk to JC regarding getting the Symphony front end development team engaged on the standard API work generally, and the notification API specifically.
  
  • Colin Eberhardt (He/Him) would like to have a call with JC to discuss these topics
• Peter Monks: Unable to locate Jira server for this macro. It may be due to Application Link configuration. is stuck - chase it up internally with Foundation staff
• All: add agenda items to next meeting (standing action item)