Table of Contents

Date

19 Oct 2016

Attendees

Actions items from previous meeting(s)

• TBD: Once POC project team(s) are identified, create CONTRIB JIRAs for the POC(s)
  • Should we remove this one?  It's been carrying over for quite some time.  I'm going to remove this one from future 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): find and share information on the pros & cons of write-once/run-anywhere approaches, the architectural implications of WO/RA on the interface, etc.
• Former user (Deleted): send URL of OpenFin API docs to Former user (Deleted)
• Former user (Deleted): establish mechanism (Confluence page?) for gathering feedback on OpenFin JS APIs, and notify WG via email
  • All: review the OpenFin JS APIs

Agenda

Meeting notes

• Jonathan didn't receive the meeting details, so didn't attend the meeting
• Standardisation / interoperability:
  • Question on "why OpenFin" rather than Electron - this was just a starting point, rather than a statement of intention.  It's one we had access to quickly.  What we wanted to do was say "what does a standard look like?  Is the Electron API too low level?  Is the OpenFin API too low level?"
  • Thanks to John and Matthew for their comments.  Did anyone else look, but didn't have a chance to comment?
  • John: when I look at the API, the purpose of the API is to put together an API that leverages it, as opposed to just defining an API.  From the perspective of someone who's used these APIs under Node Webkit and Electron, I was thinking of the kinds of things we are getting out of our web-enabled desktop apps to do, and the things that I'd be looking for.
  • James: agreed.  There is somewhat of a difference between a standardised API and a "this is how you use my product". But the goal here is to produce a standard API - we're not focused no a particular product yet, given that the Minuet contribution is in a difficult legal place.
  • Matthew: and we don't want to tie ourselves to any one vendor or product.
  • James: that's fair.
  • John: when transitioning from Node Webkit to Electron we started with an overlay so that we could make it as seamless as humanly possible to transition from Node Webkit to Electron.  They have some fundamental differences, both in philosophy and implementation.  We have a bit of a straw man for that, but I don't know to what extent we can share it.
  • James: I can look at that, in terms of IP.  If you find the doc, I can look at the IP.

  • James: anyone else have any other comments?  We've had a couple of runs at having people commenting on this.  Do the members have the right membership to comment on this?  We've talked about doing this, and I've sent out several emails,  and we're not going to progress very far unless there's participation and feedback.

  • Peter: if there's a better way to capture and track actions (beyond the wiki), let me know.
  • Rob: we (Symphony LLC) are engaging in a POC around Electron right now internally, and the reason that  haven't been providing feedback is that the LLC folks internally don't want to be hindered by participating.  I do want the results of that to feed into this group, and I'm happy to be the interface.  We are trying to engage internally and have a desire to see this work.
  • Amit: right now Symphony is doing a POC with Electron and other containers?
  • Rob: mostly just looking at the crypto side.  The person doing it is on vacation, so once he's back I can re-engage him with this group.
  • Amit: so in the next meeting you'll share some details on what Symphony is thinking?
  • Peter: this overlaps with what JC was going to present on today.
  • James: Ok given the LLC doesn't look like being able to attend, let's continue focusing on the API review.  Let's switch to looking at another container, beyond OpenFin. Electron and NodeKit being the obvious choices.  Do we feel informed enough to know what baseline we want to work from?
  • Nick: the straw man I put forth is for an interoperability layer - it's not intended to represent anything opinionated about an OpenFin or Electron API or even a commercial browser.  So while it isn't a perfect proposal, it is decoupled and is intended to support interop.  I wouldn't propose that we use the OpenFin API today then add an interop later.  I'm not sure that's appropriate, either for OpenFin or Electron.  The biggest issue with Electron is that it's API is mostly synchronous, which is problematic if you want an interop layer.
  • James: from what I've seen of the interop layers I've seen out there, there seem to be two cases:
    • Synchronous API (for notifications, popups etc.)
    • A loose binding, possibly more-message oriented API
  • Nick: which is the way Electron does it - message API and synchronous functions.  What I'm saying is that if you want an interop layer that runs on top of both, you could do it and require things to behave in a synchronous way, but you're not hitting the lowest common denominator.
  • John: messages is based on getMessage / postMessage, and the way we do is it is that it's asynchronous between apps, and the low level OS APIs are synchronous but they're not about interop.
  • Matthew: are we trying to boil the ocean?  I'm trying to get my head around the Electron APIs vs what Symphony exposes.  Are we trying to bite off more than we can chew?  I was going through desktop notifications and there's no real major standard that Symphony or Electron or Chrome does it.  I'm disappointed there's no real standard out there.  But by trying to impose the Electron notification APIs... ...it's huge - does it have to be that big?  Do we want to organically grow this?  We'll only talk about APIs Symphony exposes?  Trying to get agreement on the 30-40 APIs n Electron - is that what we want to do?
  • John: I would agree with you.  If you're going to choose a particular implementation it's based on capabilities and merits.  But if you're defining a common API that people can ensure works across implementations then you need a lowest common denominator, which is a different proposition.  This will be a smaller API not a bigger one.  I think it's smarter to start with the capabilities you need then work your way up, rather than boiling the ocean.  But if you're looking for an off-the-shelf API then it's probably better to go big.
  • Matthew: yeah.
  • JameS: yeah. I'm happy to go either way.  We'd talked about taking the de-facto interface that Symphony uses, but what we found is that the Symphony app goes around what we thought was the de-facto interoperability API (and Rob is looking into that).  Broadly speaking, there isn't that much stuff, really, that Symphony does.  If we could make a decision on which direction to go that'd be great - working up from Symphony or down from a container like electron or OpenFin.  It sounds like Matthew & John think we should be going from the Symphony requirements up, and I'm inclined to take their view.  Feedback?
  • Nick: I agree with that.
  • James: the only problem is that we're becoming more reliant on Rob and LLC in defining what their requirements are.
  • Nick: can't we start with what's in the APIs in the Symphony app-bridge JS?  Start with that, then look at how to abstract it?
  • James: yep.  How about we vote?
    • VOTE: should we commence work from the Symphony requirements up, or from the container down?
      • Bottom up: Amit, John, Matthew, Nick, Rob, James
      • Top down: Tim
      • Abstain: Emmett (deferred to James)
      • No voting rights: Peter, Gabriele
  • Matthew: ok so what are the next steps?
  • Peter: let's conduct a formal vote on "top down" vs "bottom up", then take it from there.
• Meeting adjourned

Action items

• 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
• Former user (Deleted) (with assistance from Peter Monks) run formal vote-via-email on "top down" (container first) vs "bottom up" (Symphony first) decision
  
  • Click here for the Foundation's voting rules