...

Actions items from previous meetings

•  TBD: Once POC project team(s) are identified, create CONTRIB JIRAs for the POC(s)
•  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): come up with a plan to socialise the proposed change in focus with the broader group of WG participants, and drive decisions on the following:
  
  1. Agreement to switch focus to container standardisation
  2. Agreement to punt Minuet stewardship (if/when the code gets contributed) to a project team

...

Meeting notes

• James: last meeting we had a decent discussion on whether we wanted to carry on with Minuet.  The general consensus was that it's a moot point, but in the longer term we're not 100% certain it's the direction we want to be going in.  There was a strong preference among those present to focus on standardisation of the interface for a desktop container and our continued influence on Symphony LLC to adopt that, such that the Symphony application can be used in another container.  This aligns with the POC we'd like to execute with Symphony running in OpenFin and Electron, which we're still a little bit stymied on, in that Nick did some work and found out relatively quickly that the place where we thought the interface between the app code and container code was well defined, there's leakage around that that makes it hard to identify the interface.  I'll pause there and ask for feedback, especially from those who weren't present last week?  What are your views on that topic?
  
  • Stunned silence?
  • Ed (Peter: not 100% sure who this was - please correct this name throughout if I mis-identified you!): if there's an agreement to focus on the leakage, what are the next steps to close the gap so we can standardise it?
  • Nick: after I put in the JS API that should expose the Minuet API it create d a whole bunch of errors and it was hard to step through since it was within the uglified / minified Symphony JS code.  Once it thinks it's in Minuet it just broke.  The APIs that are exposed don't seem to be accessed at that point, so I thought there were some other things saying "hey I'm in Minuet" and then that's breaking because my container doesn't support those things.  That's just based on educated guess.  For me it'd be great to talk to anybody who's been doing this on the Electron side so I can see how they built this out on the Electron container.
  • James: we don't have anyone online who's looking at that, though I know the Goldman guys were.  But I don't think Gareth has spent much time on that recently.
  • Nick: yeah I intend to reach out to Gareth.
  • James: if LLC thinks this is something we should do.  One assumes that with some effort the LLC's UI code team could identify where they're calling into the container.
  • Lawrence: that seems like alogical approach.  We'd like to have a more comprehensive discussion with the WG once we have the right participants.  Along with the WG we need a reference implementation of the standard that functions.  I think what you're saying make total sense, and I expect we'll be in a better position to talk in more detail at the next WG meeting.
  • James: a technical approach might be for Symphony to identify the interface and us to create a new version of the definition that encompasses those functions, then someone to make those new calls pass through to Minuet.  That makes it much easier for the Electron & OpenFin guys to pass through those same calls to their containers.  That would give us a literal definition of the minimal set of capabilities from the container to support Symphony.  The slightly more theoretical approach is to look at what a container might offer, but in the past we've talked about that and those conversations didn't get very far.
  • Ed: that seems like something Open Fin would want to do.
  • Nick: you could look at our APIs, which are publicly available, and what you'll see is that the API is dealing with reasonably generic window and system-level stuff.  The idea is that there's an API that are very utilitarian for a webapp to interact with the system, and the producty stuff happens over the message bus.  I did build a very similar API to this that's used in Reuters' 2000 Extra and Eichon products that's based on a messaging protocol that integrated the web and desktop parts of that product.  It was an event driven / message driven API that did the same kind of stuff.  There were fairly basic things - system level menus, desktop notifications - and then there was a pub/sub message bus that could plug in other modules that would do things like fetch specific kinds of data, integrate with the Messager system, things like that.  Those modules could be developed essentially independently of the core API and delivered separately.  This was an architecture that worked very well for us.
  • James: I'd agree that we want a minimum concrete API that changes infrequently, with more dynamic APIs that might change more frequently.  I could see more standard interfaces for the containers to implement.  As long as it's versioned it seems fairly straight forward.  I guess the question is if we were to take that route (a concrete API that's been open sourced by OpenFIN) should we take a look at that first, or is there something more valuable we should review?
  • Ed: it seems like we don't want to take one example as gospel.
  • James: no certainly not.  But it is available - Nick can point us at the URL.  It gets us past the problem of having an institution having to jump through hoops to open up their container's API docs.
  • Ed: OpenFin seems to be Web first, whereas Goldman is more .NET first, but I'll want folks internally to contribute to see what's missing.
  • Nick: what we can do today is share the PAI documentation available on our website.  We're also open sourcing the core that runs this API and we're working through that process internally, but I don't have a specific date at this time.  It'll be sooner rather than later, but certainly the docs are available today and the runtime is available today.  It's a JS API, and the source code isn't going to tell you any more about the API than the docs do.  At least for starting this conversation this seems to be sufficient, and once we have the open source this can become more collaborative work with this community.
  • James: So this JS API has modules, inter-app message bus, notification, system window management?
  • Nick: yep.
  • James: those on the call - does this give sufficient starting point?
  • Matthew: we have a Confluence site - why aren't we putting it there and breaking it down first?  There'll be a list of 20/30/40 things in OpenFin and we may not want to implement all of those up front.  There might be groupings that are easier to opine about?  Can we get to a system where everyone on this group can work at their own pace?  We've asked OpenFin to publish theirs, but we could ask the LLC to publish theirs.  All we really need is a starting point.
  • Lawrence: very valuable to get input from OpenFin and institutions who are running these things.  LLC will have opinions on what APIs & hooks Symphony needs, but that's likely to be a subset of what folks looking for a general purpose wrapper need.
  • James: very happy for people to put comments on the Confluence site.  We could copy the OpenFin API doc across - if practical.  There's no reason we couldn't put some structure around the Confluence site.
  • Matthew: perhaps we have to come up with one interface or comment ahead of the next meeting  If we start putting out custom ones in there it might deviate from what's already been thought out.  So I see a benefit in seeing the most used interfaces in the OpenFin container - would be a great benefit for this group.
  • James: OpenFin have made their API available, but my proposal is that we all look at the OpenFin JS Doc, but then we structure the feedback around the modules and encourage everyone to give feedback on Confluence.  General comments on that structure are also useful.
  • Matthew: that starts the conversation, so I agree.
  • James: any other ideas?
  • Ed: do we want to draw parallels to things we would want Symphony to do?  There's the pure vision of desktop containers, then there's the specific use cases this particular application has.  Should we remind ourselves what we need to baseline against Symphony?  Things like tear-out support, window docking, window placement, and memory between launches that the web version of Symphony doesn't offer.  If we go generic we could be here for years.
  • James: we could also put together a page of specific requirements.
  • Ed: it seems easier to start with the specifics.
  • James: happy to capture that.  Some of it ends up being product stuff for LLC.
  • Ed: I'm only talking about how that would drive the desktop container.
• Action item review
  • No word from Rob Wisniewski (Github repositories, suitable engineers to include in the WG, etc.)
  • Lawrence: <regarding potential charter changes> would suggest waiting for a few more meetings before formalising that.  There may still be some code-related activity (I'm hoping).
• AOB:
  • <none>

Action items

•  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