...

Actions items from previous meeting

•  Former user (Deleted) to revise charter, with an eye to removing the Minuet objective and tweaking the standardisation objective if needed, and distribute to group for review
•  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 when development might start
  
  •  Former user (Deleted) (with assistance from Peter Monks): schedule a session with LLC engineer(s) and volunteers, to capture that list

...

Charter Update (Draft)

Current charter: WG Desktop Wrapper - Charter.

Draft new Charter: 

1. The group will seek to define and standardise APIs required to integrate the Symphony HTML5 application into a desktop container, with a specific goal such that applications such as Symphony might be hosted in different containers/frameworks. Standardisation may take the form of identifying the relevant standards (i.e. W3C standards) or authoring new standards as relevant.

2. The group will seek to influence contributions to the Symphony Desktop Container project(s) in order to both enable 1 and expand on the capabilities of that container as Foundation members require. This influence will happen through working with Symphony LLC and direct contributions from the Foundation members.

3. The group will seek to influence the direction of the development of the 3^rd party integration APIs used to interact with the Symphony Desktop application, both as they relate to 1 and as they evolve which may include more general desktop application interoperability either via local interfaces,  server side services, Symphony messaging etc. This influence will happen through working with Symphony LLC and direct contributions from the Foundation members

NOTE: JT has a concern that we need to balance what we the WG can influence vs. what we would need LLC to undertake and the objectives set out above may be too dependent on LLC.

Meeting notes

• Update on Minuet parity work:
  • James: without JC present there's not much we can cover here
• Charter discussion:
  
  • Colin: the primary goal seems to narrow the goal, but what about APIs that support financial applications in general?
  • James: we have talked about that - extending the APIs to be about integrating financial applications.  I personally put that down as a stretch goal, in that I would like to do something that has the "right size" to it initially - highly correlated to Symphony itself,.  If we're successful in doing that we might stretch ourselves to do that.
  • Colin: I get your point - this gives us a tangible goal vs something that's a bit more woolly.
  • James: has everyone reviewed the updated raft on the web site?
  • Amit: on the second bullet - it's basically thinking about upgrading the container?
  • James: the second bullet was to try to influence the implementation of the Symphony desktop container, in order to implement bullet point #1.  My intention with the 2nd bullet was to say "while this group is not the primary influencer of the desktop container - that's the LLC - we do want to have some influence so that we can achieve the first bullet point."  We would like to influence the LLC via JC's participation in this group, but also (and I know the LLC is keen for this) for us to directly contribute code to the open source project.
  • Amit: and the direction is to move away from the Minuet desktop towards Electron?
  • James: in the last few meetings we've taken some straw polls on that, and previously the goal of governancing Minuet was effectively moot, because:
    • Minuet hasn't been contributed (though there's an update on that).
    • If the Symphony LLC strategic direction is moving away from that, and while JC didn't formally confirm that he indicated that Minuet is moving to maintenance mode, with a switch to the Electron based container - but the feeling from the WG two weeks ago is that continuing to governance Minuet isn't where we want to expend our effects.
  • James: Peter - can you give a quick update on Minuet contribution?
  • Peter: sure!  Just this week we received the signed CCLA from Goldman legal.  Next steps are to take delivery of the code and license check it (to ensure compatibility with Apache), and schedule an ESCo approval vote (which I expect will be a formality).
  • Lawrence: Goldman have signed the CCLA, but we haven't received confirmation on whether they need to take any other procedural steps.
  • Aaron: I can confirm that there were additional steps Goldman needed to take - e.g. code scan to ensure they're not releasing things they don't want to - but those steps are complete.  We are still working to identify which of the two forks of Minuet will be contributed however (Goldman fork vs LLC fork).
  • James: thanks for the update, but I think we know where we are with Minuet, and it's of decreasing interest to us.  Let's refocus back to the charter.
  • Leslie: point 1 talks about the Symphony Javascript app interacts with the container - is the point of point 1 that the APIs the Symphony JS application uses are identified, reviewed & standardised, so that the Symphony webapp can be dropped in another container?
  • James: yes.
  • Leslie: and point 3 talks about APIs for connecting desktop applications?
  • James: there are 2 APIs:
    • "internal" technical API that allow the Symphony app to pop alerts, manage windows, etc.,
    • integration APIs that allow you to add your buttons and hook in actions to those buttons - a suite of integration APIs if you will.
  • Leslie: and presumably those would include "on behalf of" operations?  The Symphony desktop running in a container will offer a local websocket interface?
  • James: in the last meeting there was some discussion about how robust the current desktop APIs are for doing certain things, and how it might be better to go via a web service interface provided by the Symphony pod.  So to give you a use case, you might imagine something that needs to hook into the desktop to create a button, and for some reason that's a bit flakey through it's lifecycle (e.g. button becomes unavailable, callbacks stop working) - you can instead imagine the call being routed by an inter-app messaging interface on the pod.
  • Leslie: the problem is in getting the associations between some random application and a specific running instance of the desktop application.  But my point on point 3 of the charter, would be to make it clearer that it's about integration between applications.
  • James: that's fair.

  • Leslie: yeah point 3 is for external developers vs point 1 which is really internal.  Separately I'd love to have the conversation about desktop message buses.

  • James: yeah there's been a lot of talk about how integration might work, and how we might governance that via working groups.  It's partly a question of focus - multiple groups of people talking about it, and we just need to do a better job of coordinating amongst those people.
  • Peter: there's been some Platinum member / ESCo / BoD discussions about this - desktop integration might potentially become new WG, or a sub-group of this WG.
  • Lawrence: it would be good to have this on the agenda.  If we're talking about setting up a new WG it would be good to coordinate with this WG.
  • James: if someone can give me the contact information for the gentleman at Deutsche Bank I can investigate.
  • Peter: I'll take the action to introduce you.
  • James: I'll also invite him to present to this group.
  • Matthew: one piece of feedback on the charter.  The first point is "define the standard", the others seem to be "influence".  I like the use of the language, but it worries me that it's all about "influence" - it's hard to know if it'll be successful.
  • James: there is a rationale behind that - we don't control the Symphony container project; the main contributor is the Symphony LLC team.  We can seek to influence in 2 ways - JC's big preference is via code - it'll speak substantially louder than pontificating on a call.  But we have to accept the fact that we don't control the code - we're not setting up this WG to be the benevolent dictator of that project.
  • Matthew: agree, and I'm fully behind #1 & #2 - they're really good.
  • James: any other feedback?  ...   I'll do a final bit of tweaking and we can move to a vote, propose to ESCo, etc.  One request - we're a little bit dependent on the Symphony LLC, specifically JC joining this call for our current agenda - so I'd put out a request for anyone who has a topic they'd like to talk about to get it on the agenda.  I will get the representative from Deutsche Bank to join as soon as he's able to talk about interoperability.
  • Leslie: big thing for us is "on behalf of" - AFAIK we can't use it to receive messages in Excel RFQ.  It's meant to be that you post from Excel or desktop apps or whatever, and the RFQ goes out on behalf of that user.  For the hackathon we had to have a separate bot user for each Excel user, which is just not practical.
  • James: are you using the REST API?
  • Leslie: .NET wrapper API.
  • James: yeah which wraps the REST API - which is sadly not great for this type of integration
  • Leslie: point 3 doesn't offer what we need to both send and receive messages on behalf of a user
  • James: yeah we've had that conversation with Symphony as well.  Lawrence may know more about this than I do, but I believe an explicit decision was made not to support this.
  • Lawrence: I'd suggest talking to the product team directly - the APIs have been through a lot of development recently.
  • Leslie: who should I send it to?
  • Lawrence: I would ping Paul Teyssier, or you can connect to him on Symphony chat.  He's the product owner for that, and you can mention I suggested that you ping him.
  • Leslie: thanks
  • James: if you find out what's going on there it would be good to give an update - it's a great requirement, and if it's not on the roadmap we can add it on to our list of things we'd like to influence in the desktop container.
• James: if there's no other business, let's adjourn early - thanks everyone!

Action items

•  Former user (Deleted): refine language in point 3, based on feedback from Leslie Spiro and the group
•  Peter Monks: introduce Former user (Deleted) to Jim Adams @ Deutsche Bank.
  
  •  Former user (Deleted): coordinate with Jim regarding presenting to this WG on how desktop integration discussions can best be facilitated
•  All: identify potential topics of conversation while we wait for JC to re-engage with the WG
•  Leslie Spiro: get in touch with Former user (Deleted) regarding "on behalf of" API capabilities
  •  Leslie Spiro: provide an update to the WG on whatever is discussed