Table of Contents

Date

29 Nov 2017

Action items

Add new action items here.

Meeting notes

• Action Items:
  • Scriptable save & restore proposal, and windowOpen:
    • Nick: I produced both of those things, as a single proposal, since they're related.  I think we need hooks that allow a wrapper to save and restore state, but at this point my opinion is that we don't need a specific SSF API for this since there are too many internals shared between the Symphony app and the wrapper.
    • Leslie: I completely disagree, so I'll come up with a save / restore proposal
    • Nick: ok so maybe it would help if we went through my proposal first?  And we can talk about state and how that would look?  I don't mean to hijack the agenda, but I have a hard stop at half past, so if we want to discuss it we should do it now.  So the proposal is for two APIs - window.open is clear and I'm sure everyone understands that.  The other API is a way for the Symphony app itself to pass a function to the wrapper when it wants to basically initialise or initiate a chat state.  If a desktop wrapper is restoring state, it would call the function provided by Symphony to that API, passing it the ids associated with the chat (or the states it has stored).  If it needs to bring a chat into focus or creation (e.g. due to notification) it would call that function as well.
    • Lynn: why do want to put this state in the wrapper?  I think the app that runs inside the wrapper should be responsible for state.
    • Terry: this allows the application outside to get to it.  The wrapper is just a go-between.  The wrapper itself wouldn't handle that.
    • Leslie: Our view is that the container will hold the state, since that state may include more than just chat (market data windows, etc.).  This is a pretty common pattern for desktop apps.
    • Lynn: but the container is only running one application at a time.  If you want another container you run another instance somewhere else.
    • Nick: the tricky thing here is that for you that's the case, but for most of the groups who'd want to integrate Symphony via this API it's explicitly not the case.  Which is why they have their own wrappers and want to do these kinds of integrations.  The balance I'm trying to strike here is perhaps overly pragmatic, but this API continues to treat the Symphony app as a black box, and the Symphony application would relate some container state to its own internal state, via ids.  Based on the id the Symphony app would make the window.open calls that correlate to that state.
    • Leslie: the issue is how do you get the state.  I'll do a proposal, since I don't think this is what we'd previously agreed.  We can then compare it to this proposal next meeting.  Then we can talk about what approach makes sense in terms of the SSF API.
    • Lawrence: is there also a user functionality implication to this. If you, as an application designer, allows users to lay out windows a certain way and the user moves to a new machine, don't you want to replicate that layout?
    • Leslie: that's exactly the idea with what we agreed to document in our last meeting - get state & restore state.  In my view it does make sense to me to ask an application for its state as a blob, then I give you the blob back to recreate it.  But let's do it in the context of a couple of proposals so we can properly discuss the alternatives.
    • Nick: fine with me.  Is there any way to decouple these things?  I think what you're proposing is great, but it's longer term and brings in additional variables that we'd need to address.  What I'm trying to describe here is something more pragmatic - I'm keen to get a read if these are things that we can move forward on and go deeper on defining.  These are very real needs that we're trying to address right now.
    • Leslie: so you've got two APIs here - and I think there's an understanding that windowOpen goes through a wrapper function.  setChatFunction needs to be looked at in the context of state restore.
    • Nick: this isn't just about state restore - it also addresses for example a notification.  We don't yet have an API to tell the Symphony application that a notification has been clicked on and you need to bring it into focus, since that chat may be in the main window.  Right now there's no way to do that - to tell the application that the existing chat needs to come into focus.  This is one of the main use cases this proposal is trying to address.
    • Lynn: I don't understand the click on notification - we've already implemented that.
    • Nick: how do you tell the main window that the notification has been clicked on?
    • Lynn: if you look in the code, there's a click handler that's passed into the notification and we use that, and that calls back and provides a handle.  Let me check the code...
    • Leslie: can we take this offline?  I don't see setChatFunction as a good way to support this - I see a separate API around notifications that sets a cookie or something.  So I'm inclined to get a proposal together that looks at these use cases in context.
    • Nick: ok
    • Lynn: so we do have a click handler that calls back to the Symphony app, which activates a window if it needs to.  So as far as window.open - it looks fine.  I'll need to do some prototyping, but it looks ok.  Though there's no return value defined - I assume this API needs to return a handle?
    • Nick: yeah that's an oversight, it'd return a handle.  To clarify, you'd expect a handle to the DOM window?
    • Lynn: our current code expects a return of whatever window.open returns.
    • Nick: yep that's a DOM window.
    • Leslie: Nick would you mind splitting the document to put windowOpen and setChatFunction separately, so we can move on and have Lynn confirm that the window open proposal will work?
    • Lynn: yep I can then have the internal folks here look at it.
    • Nick: yep I'll paste it into the existing wiki.  One other thing I want to raise: I believe there's been a new release of the Symphony app (1.49 I think?).  Were there any wrapper or SSF API updates on that?
    • Lynn: nothing has changed in the raw wrapper there.
    • Nick: ok good.
    • Leslie: and semi-related - Nick has been reporting sidebar count number differences between Minuet and SymphonyElectron.  Has the LLC had a chance to look at that?
    • Lynn: yes QA reproduced the issue and have raised a bug.
    • Leslie: and this has nothing to do with the SSF API?
    • Lynn: that's correct.
    • Leslie: ok great - thank you Nick for finding and reporting a Symphony bug!  
  • Plexus interop:
    • Leslie: acting as a participant for a moment, I thought the Plexus interop presentation was interesting.  I thought it was very light on what Plexus interop will do once it's running with Symphony.  I'll raise this with Slava and I don't know if anyone from the LLC has comments on bundling Plexus with Symphony?  Has any statement been made about that?  Is there a date?
    • Lawrence: I haven't had an update since the last non-update I gave.  
    • Leslie: ok let's pick it up in the new year then.
• OBO:
  • Leslie: I don't know if anyone had a chance to read it, and I'll talk through it since it's not very long.  This is a real use case we found.  A year ago we were looking at a POC for a potential product to run IOIs over Symphony, using Glue for interop.
  • Lynn: what's an IOI?
  • Leslie: an Indication Of Interest - basically an RFQ.  You throw out a request to multiple parties and they independently reply (or not) to it.
  • William: IOIs and RFQs are different though.  Are we saying IOI transmission of data .e.g T Bonds for $30 million expiring at a particular date?
  • Leslie: very important question, but for the POC it was a more general question of whether we can securely transmit these kinds of things over Symphony.  So there is a huge difference between IOIs and RFQs but that wasn't the point of the POC.
  • William: are we facilitating the transmission of the data, or sending a link and clicking out to some other app?
  • Leslie: assume there's a vendor who wants a mechanism to send some data about an IOI or RFQ or whatever (could be anything).  It's running in the user's non-Symphony context - a browser webapp, container app, desktop app, whatever - and there's an implicit data exchange to an app on some other user's desktop.  We wanted to look at using Symphony for that data exchange.
  • Nick: is this financial objects?
  • Leslie: it could be, but the point is to do it from a desktop application.
  • William: but that's a combination of passing an object with a defined schema through a pipe, and that pipe could be through a container?  It's just that the consuming application has to understand the object?
  • Leslie: agreeing on data structures is a different problem.  Imagine I've got some application and it needs to get some data to some set of users in another organisation, into applications running on those user's desktop.  So I want to send data from, say, my Glue RFQ desktop app, via Symphony, to another user's desktop app.
  • William: I understand, but what's the user experience?  If I'm sending an object to Dov, what does he see in Symphony?  A link, or ...?
  • Leslie: the absolutely key thing is that the user experience we as a vendor wanted to provide is to have some desktop application send a message and appear directly in some other desktop application, not the Symphony chat UI, but using Symphony as the data pipe.  It might be that Symphony won't support this model, but that's the user experience we want.  Our tagline is "Symphony chat is not just for people" - we're talking about using Symphony as a pipe to allow interop to work not just within a single user's desktop, but between different users' desktops.
  • Terry: this sounds a lot like the "conversation client" that was supposedly under development at Symphony.  Are you familiar with those developments?  It gave the ability to embed the chat context in some other app.
  • Lynn: we have embedded chat already, but it's basically just taking a single Symphony chat and embedding it into some other webapp.
  • Terry: can the enclosing app communicate with Symphony via JS calls?
  • Lynn: it's in an iframe, so...
  • Leslie: this is the use case we're interested in.  And it kind of relates to some of the things Plexus might be interested in.  Of course it can be done with a server application, but we'd like to simply deploy a desktop app and not require another server-side install.  Do other community members think this is interesting or useful?  If so, would LLC consider supporting it e.g. by extending the wrapper API?
  • Johan: we use server-side OBO for this.  The simple fact of finding a user in another application and sending them a message from our application via Symphony is implemented, but it requires a FactSet server component and a mapping between Symphony users and FactSet users.  If we'd had the functionality you describe we wouldn't have used server-side OBO - we would have done it all locally.  So yes we are interested!
  • Terry: yes we are eagerly anticipating this capability at ChartIQ, so we'd be all on board with this, if it were at all possible.
  • Leslie: it's basically about making the Symphony app scriptable.  Dov, Brian - what's the interest for you?
  • Brian: the embeddable chat is my next project.
  • Leslie: so Lynn, Lawrence, representing the LLC, is this something we can formally raise from the WG to express an interest in this?  Can we have the Symphony wrapper add an API, or embed an interop solution of some kind?
  • Lynn: why not use server APIs?  Adding complexity to the client is problematic.
  • Leslie: operationally, getting a server deployed is hard for many of us who work in large investment banks.  Secondly, as a vendor (and I assume OpenFin and ChartIQ would agree with this), going in and saying "to use this you need to install a server and validate it into the Symphony ecosystem" is difficult.
  • Lynn: it's not the modern way to do things.
  • Leslie: I don't agree with that.
  • Lawrence: not to interject, but you're raising a topic about workflows that broadly speaking we want to support.  I know we've discussed this kind of workflow with customers.  You've asked Lynn and myself to respond on behalf of Symphony, but it goes beyond Lynn's role as Container lead and mine as CSO.  I'm not saying it's a bad question or don't welcome these discussion, but we do typically have detailed engineering discussions with those looking to build these kinds of integrations, via our partner team.  When there are functional or technical gaps we work with the platform team rather than the desktop / container teams.  So don't take this the wrong way, but I'm not sure Lynn and I are the right people to give a statement.
  • Leslie: in raising this I was hoping to see if there was interest beyond Tick42 for this (and there is some), and then to raise it with the LLC.  I do want the use case to be understood, and the point that Lynn made about using REST APIs for this is true, but there's also a movement towards desktop interop as there are different benefits (and challenges) vs server side approaches.  So Lynn, Lawrence, if you can raise this in the appropriate places, perhaps the API WG?
  • Lawrence: yes the right thing is to submit it through that channel.  Generally speaking the use case you're talking about is not unfamiliar or novel in terms of things we're trying to support.  It's not something new, but it's certainly good to hear from customers & partners so we can apprise the interest.  Then we can more directly with you about what the API options are, next steps, and sometimes they can help guide an engineering discussion towards a specific architecture.
  • Leslie: ok I'll send this off to the API WG and report back.
  • Lawrence: I'm appreciative that you've taken the time to describe the use case.
• Proposal for additional API coverage:
  • Leslie: Nick would you like to add anything here?
  • Peter: Nick dropped about 20 minutes ago
  • Leslie: ah ok
• AOB:
  • <none>

Agenda

Attendees