...

Actions items from previous meeting

...

Background

In discussion at the group last week, it was suggested we make a formal decision between the approach for standardising the container API. We had been looking at a couple of different APIs (OpenFin and Electron) which are broad and would potentially cover a large number of requirements outside of those needed for Symphony. It was suggested this might be too wide and that we should go back to taking a “bottoms up” approach to standardising the container application interface, i.e. looking at the de facto requirements for the Symphony application first and finding the best API(s) to satisfy those requirements.

A straw poll on the call showed majority support for this bottoms up approach, but to formalise this decision I would like a vote from the WG members.

The Vote

Proposition: Do the WG members agree to take the “bottoms up” approach (as described above) to standardise the container API?

 +1 approve the proposition

-1 deny the proposition, because...

0 abstained, because...

The Results

Meeting notes

• Vote recap - James
  • The vote on standardising bottoms up was unanimous.  But as a practical matter, we can't send out the API to every member of this group right now.
  • Matthew: why not?
  • James: because it's not open source.  It's owned by LLC.
  • Nick: can we work with what the functions are?  Do we need the actual code, or just the API descriptors?
  • Matthew: can we not take it, take out the API, and the actual code, and work with the empty shell of the code?  Or do we need to describe every API (which shouldn't take long either)?
  • Gareth: wouldn't we work from the API signatures?
  • James: are there signatures we can release?  Though I haven't looked at it in a while...
  • Nick: I looked at it last month, some APIs will be somewhat clear in purpose, others may not be so clear.  Some of the signatures return an opaque object (like the configuration object).  But it's a starting point to the requirements for what a container would need to do.
  • James: yes the intent is that we can create a standard e.g. for notifications.  It's a requirements thing more than a literal signature thing.  So I think we need to go through that JS and turn it into requirements.  Do we have a volunteer to do that?
  • Matthew: I can help, if someone else wants to work with me on it.
  • Nick: I'll work with you on that.
  • Gareth: happy to review what's there.  It's not hard.
  • Nick: I'm going to be in London and we could sync up in person?
  • Gareth: great - let's meet up and get it done.
  • James: ok great I'll leave it to you guys to organise.  Will you be done in two weeks for the next meeting?  Is that Thanksgiving?
  • Nick: no.  I'll be there the week of the next meeting.
  • Gareth: let's do Tuesday the 15th.
  • James: Great! Any other actions to come out of this? We would have a preference, where there is one, for W3C APIs.  That needs some unpacking, as some W3C APIs, while fit for purpose, are a bit minimalistic (e.g. W3C notification API).
  • Gareth: why wouldn't we use those as a starting point?
  • James: straw poll - is this a good guiding principle?  Does anyone object to using W3C standards as a starting point?
  • <general agreement, no objections>
  • Gareth: how about we use W3C first, Electron API second, then other containers third - better to reuse rather than reinvent.
  • James: sounds like we're good with that as a soft principle.
• Action item review - James:
  • Rob from Symphony has a bunch of actions, which I don't know anything about and he's not on the call.
  • John (de Murga) was going to generate docs for us.  Unfortunately there's a bit of additional i-dotting and t-crossing to be done with our contribution agreement.  John can generate the docs, but we can't contribute them quite yet.
• AOB - James:
  • JC from Symphony was a no-show last meeting, and was unfortunately unable to join us today, but he'll be joining us in 2 weeks.  Any other business? Seems like we should have a document to look at before we go too much further.
  • Matthew: what are our next steps after we write up this list, look at the APIs they've got?  Chances are we'll look at those APIs and say "those aren't in line with W3C APIs", and we'll go to the LLC saying "you need to move to the new API", retrofitted to Paragon and Symphony.
  • James: long term perhaps, but for now "minimum set of things you need to support right now"  We're proposing the standard API looks like this - there's a piece of work between identifying what the API looks like, and what we'd like to present as a standard.  Probably also some running around to say "how does that compare to OpenFin, Electron, node" and there's potentially some scary work ahead on that front - if we want this to be a standard how do we influence these people?  It may be easier to code a shim such that if we want Symphony to work on these containers, by complying with the standard and using a shim, it works on those things.  Then longer term we start to influence these folks.
  • Gareth: if we think specifically of Paragon and OpenFin, we have two key people here, and we all want the same outcome, so it doesn't seem insurmountable.
  • James: and we've heard from the other firms that they have internal builds too.  Influencing Electron etc. seems like a longer term goal, after we have some level of adoption.  But if someone has an internal container that you want Symphony to run in, then we might say "here's the API Symphony needs", and folks can build their own shim.
  • Dov: at some point it's ok to open the kimono on this and share a generic container framework.  It's not a competitive advantage at this point.  I could share ours, GS has already shared theirs, etc.
  • James: if Symphony say that "ok the Desktop Wrapper WG has identified a standard to support Symphony", then everyone can internally add a shim to their containers.
  • Dov: absolutely.  Perhaps a show and tell would just make this tangible.
  • Gareth: for folks who've worked on lots of containers it's easy to take for granted how abstract it all sounds.
  • Dov: my gut tells me it'll be more productive if we share.  But a shim sounds like a good idea, even if Symphony didn't exist.  I can talk to the folks here to see what that might look like.  I'm sure others would do the same with their groups.  In terms of calculating a deliverable from this part of the conversation, are you asking for people who want to propose a shim contract?
  • James: more that the direction we're going in is that we have volunteers to look at the de-facto contract between Symphony app and Minuet.  And if we take a look at that and say "there are these 5 things Symphony needs to do" and for each of those we define what a standard API for each of those things would be.  Then each of us would take that away and start thinking "how would that work in my container?".  We're creating a concrete standard that would work for Symphony - we'd want Symphony and the container implementers to take that away and look at it.
  • Dov: perfectly fine.
  • James: do we have a commitment that the LLC will adopt this?  No - we don't have a hard commit on this, but ESCo has had conversations on these topics, and to a degree if this and other WGs are making proposals that the LLC ignores, then we're all going to get rather bored.
  • Dov: between now and when we next convene, what sort of information do we expect to be disseminated?
  • James: the timing isn't great, since Gareth, Nick and Matthew will meet the Tuesday before the next meeting and produce some documents for us to look at, which is only just before the next meeting.  But that's the day they're able to get together.
  • Dov: so we have two / three meetings between now and New Year?  Working backwards it'd be nice to work out what we can achieve.  We have some good momentum and I don't want that to due over December / January.
  • James: after we've identified the APIs, figuring out what the standards would be for each of these APIs?  There's just not all that much the Symphony client does.  Probably the most contentious discussion will be the loosely coupled messaging layer - Nick uploaded a paper on this for our discussion.  I think the APIs themselves will have minimal discussion.
  • Dov: for the foreseeable future it seems like the container will be Minuet.  At some point they're likely to be talking apps, SSO, etc. and how does this API play into leveraging some of this desktop functionality, should we get to that point.
  • James: Personally I see a lot of the complexity around that bit - the container itself is relatively easy.  As Symphony and other companies expand in all of these directions, those desktop integrations become more interesting.  I'm very interested to see what the LLC have to say about this kind of topic.
  • James: AOB?
  • James: Please send any questions for JC to me ahead of next meeting, and I'll forward them on.
• Meeting adjourned early (new record!)

Action items

•  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