Table of Contents

Date

11 Jan 2017

Attendees

Actions items from previous meetings

• Former user (Deleted) to generate docs from CS shim, and send to Former user (Deleted)
• Former user (Deleted): schedule meeting with JC and Matthew Gardner to discuss WG ↔ LLC engagement model
• Former user (Deleted) to review charter items, with an eye to removing the Minuet objective and tweaking the standardisation objective if needed
• Former user (Deleted) to setup a 2017 meeting schedule
  
  • Peter Monks to offer the Foundation's Webex for the fortnightly calls

Agenda

Meeting notes

• Roll call
• Charter:
  • James: we're considering looking at new and exciting desktop wrapper, and interoperability.  Don't have anything worth sharing on the text of the new charter yet though.
• General updates:
  • James: Any updates on anything?  Any progress over the holiday period?  Symphony LLC - any movement?
  • JC: our mandate to get moving on this project has increased since the last meeting due to customer demand.  We'll be spinning up the team and pretty quickly people should see more contributions to the code.  Our first block of work is focused on getting parity with Minuet feature set.  One area to look at is the embedding API and whether we'll keep it on the wrapper side, or move it to the Cloud.  No good assessment yet on which way that would go, but if I were a gambling man I think it will probably move to the Cloud.
  • James: I'm sure this group is interested in that - any more detail?
  • JC: this is the webhook API that's included in Minuet that allows a typical scenario like displaying presence or putting a button in the Symphony UI that invokes something on the desktop in another application.  It's been used for telephony and things like that.  But rather than using a websocket to localhost, we want to move it to the Cloud.
  • Matt: we're excited for this to move to the Cloud as we found the desktop-side functionality unstable.
  • James: sounds like an interesting topic to talk about.  I don't know how many other people on the call have used this.  Would this be getting rid of some of the desktop integration capabilities and moving them to the Cloud?
  • JC: that's the current thinking, but we're at the very first steps of this.  Lot of variables on the desktop side that cause the websocket way of doing things to be flakey.  Also it gives us the ability to expand the API and make it more generalised.
  • Matt: we've had recent conversations at Blackrock to open source our "click to dial" functionality (which uses Avaya), but to do that we'd need these APIs to move to the Cloud, so that every firm can get click-to-dial.  If this works out and goes server side, it should spawn a load more open source projects that work across enterprises.  Open source "click to dial" - who wouldn't want that!
  • James: it piques my interest - I have a lot of questions.  Are others interested in finding out more about the intended solutions here?  There are a whole bunch of questions this brings up - does "via the Cloud" mean "via our pod", for example?
  • JC: yes you're exactly right - by "Cloud" I meant server side rather than client side.
  • Johan: from FactSet's perspective - we used the desktop APIs extensively in the beginning, but have moved to the REST API and would like to see enhancements like "on behalf of".  Many of those endpoints are being built to bring parity with the original desktop APIs.  We're absolutely interested in hearing whether these APIs would merge, or whether the new embedded API would be a better option for us and our clients.
  • JC: yep.
  • James: the question then is when would you feel comfortable to present more and get feedback from this group?
  • JC: I need to rope in the platform guys and get Paul involved.  Perhaps before the next sync up we'll be able to have a directional discussion.
  • James: pushing UI changes specific to a given user's pod to the server side seems like a more robust solution.  I know that some of our members have expressed interest in desktop-to-desktop integration.  Thinking about this strategically, would this requirement / capability go away?  Historically GS used this to integrate all sorts of other apps together.
  • Gareth: I'm not precious about how that works.  I don't know if we want the past to dictate how things are done in the future.
  • James: one argument is that desktop apps may want to message to each other, via Symphony.  The server-side approach requires a pod however.
  • Gareth: our message hub can adapt to that - I don't have concerns.
  • James: the literal desktop bus capability might disappear.
  • Gareth: is there a need to support both?
  • JC: we'll dig into this in the coming weeks as we plan for feature parity with Minuet, based on the project.  We'd very much like to have active input and contribution for anyone who'd consider using it as a general repository for work they're doing on their wrapper.  There's room for enough variation in the project that we could accommodate multiple use cases and build something that's more general than just being a Symphony wrapper.
  • Gareth: would you look at making some of those features modules?  e.g. the encryption piece.  So if we had our own container, we could still reuse as much as possible?
  • JC: we'd have to get into the architecture discussion as we add on the features, but there should be a general extensibility framework for it, so that the things we're doing are not super proprietary.
  • Gareth: one example we had is things like where you store your logs e.g. locally vs centralised logging.  Being able to tune that kind of thing is a potentially useful aspect.  And if we could use something off the shelf that would be awesome.
  • JC: getting these requirements together as we standardise the app → wrapper interfaces would be a great way to take this forward.
  • James: agreed.  We end up with the open question on the process of how do we go about building the standard interface and getting agreement across all the members of this group?  The action would be to get to the point where we have a more broadly working version of Symphony and can say "this file is the interface".
  • Peter: it would be good for the standard to "run ahead" of the engineering work, to avoid rework down the road.  I'm thinking a fairly brief (hour or two) session with a Symphony-app-knowledgable LLC engineer to identify the high level capabilities Symphony needs (window placement, multi-window management, desktop notifications etc. - all the things not provided by a W3C browser API), then this group could come up with the standards for those things.  Of course new APIs will likely emerge as LLC engineers work on the app, but we could add those to the standards as they're discovered.  JC, am I right in thinking you'd prefer to see those standards up front?
  • JC: yes.  On the engineering side, without that standard, building those interfaces would be very ad-hoc - we'd just build things as we needed them, both in the container and the app.
  • James: so we might need to invest a bit more time up front on both sides, to do the design of what the API looks like.  That still requires some investment from LLC to scope that, then as things are discovered they are iteratively added. 
  • Peter: JC would you be willing to commit to that investment?
  • JC: absolutely.
  • James: let's aim for that then.  If you could come back with a "when" that'd be good.
  • JC: what's the forum / who would participate?
  • James: come back with what's your preferred way of defining the interface, then we'd ask for volunteers from this group to work on the standardisation exercise.
• Charter revisions:
  • James: in the update to the charter that I'm currently working on, we'll be removing the commitment to manage Minuet and probably the main thing we'll talk about is standardisation.  There's probably something to be said around helping to manage the project, but I'm not yet sure what that might be - I'm in the process of getting input from others on that.  But based on the feedback from last year it sounds like pople will be happy with that work.
• AOB:
  • <None>

Action items

• Jonathan Christensen: schedule update to the group on the details of the Minuet-parity work for 
• Former user (Deleted): identify interested volunteers to work on the app → container interface standard
• Jonathan Christensen: identify a suitable LLC engineer(s) who can discuss the high level capabilities the Symphony app. requires from the container provide Former user (Deleted) with an ETA on when 
  
  • Former user (Deleted) (with assistance from Peter Monks): schedule a session with LLC engineer(s) and volunteers, to capture that list