Table of Contents

Date

15 Nov 2017

Action items

Add new action items here.

Meeting notes

• Action item review
• OBO Use Case review:
  • Leslie: action item not done, so push to next time
• Proposals for additional API coverage:
  • Nick: we've been plugging away at our integration.  In doing that we've found some additional things that we would see as improvements to the API and wrapper to fully integrate with the Symphony app.  The main things that we're looking for have to do with the ability to have more handling opening of windows as well as restore and focus on conversations.
  • Tom: one of the things that would make it a lot easier is being able to use our own API call to open up a new window, and the way it's written we can't override window.open since we use that and that would result in a circular call.  If we had an ssf.windowOpen then we could use our API there, and on the Symphony side it would solve a lot of problems.  It also solves the restore & focus problem with the activate API - it allows us to know the window names on our end.
  • Nick: the crux of the problem is that the URL is being used to open the URLs is opaque to us - it includes the stream id and window name that we don't have access to.  So if we could parameterise those items so they're real things within the API that we can get a handle on, it would allow us to programmatically open windows for specific conversations, and bring those back into focus when there's a notification, for example.  As well as allowing restoration of window configuration on relaunch.  I think this is for Lynn - do you think this makes sense?
  • Lynn: the underlying technology to open up a window?  What are you using?  Is it Electron.createBrowser or whatever, or a new process?
  • Xavier: under the covers it's eventually a window.open.
  • Lynn: so you're eventually using window.open?
  • Xavier: in the electron world window.open is decorateddeprecated, but ultimately it's still calling that.  Being able to delegate the create lets us go through an OpenFin channel.  We'll automatically track location, for example, allowing us to spin windows back up out of local storage, without having to track these opaque stream identifiers etc.
  • Lynn: sounds reasonable to me.  I was going to make something on the ssf.windowOpen oiginally but don't know where that ended up.  Why not make a proposal for the ssf API.  My only concern from the Symphony side is that our current code base - the reason we use window.open is because there is some legacy code in Symphony that depends on that.  With window.open, the parent can get access to the child and set things on it, and we have code that does that.  If someone else implements window.open and opened it in a different process for example, we'd lose the ability to do that - it'd break the Symphony code.  It's something we're fixing and I want to find a way around that, but it's something to be concerned about.
  • Xavier: I don't know which version of Electron this works against, but in most versions of Electron window.open opens a separate process anyway.  Knowing what we need to keep so your stuff doesn't break is important, but in Electron this would be broken anyway.  In OpenFin this is standard CORS rules.
  • Lynn: window.open returns an opener event, etc.
  • Xavier: that's the big one - content.window - the two way bridge there.
  • Lynn: yeah we have code that uses window.opener and things like that, and so we'd depend on that being there.
  • Nick: <breaking up> that'd be true of any wrapper, built by anyone is that they'd want to hook into that.  We can put in a proposal for that this week, and maybe kick it back and forth offline then get it signed off.  I think the question is how quickly it can be implemented on the webapp side, since that's a total black box.
  • Lynn: yep yep.  Probably what we'd have to do is support both for a while.
  • Nick: so one other thing - a more minor item.  Within the 3rd party apps in the app store, they'll sometimes increment the unread message badge, and it looks like that's not going through the SSF API.
  • Lynn: none of that does.  Those apps all run in an iframe, and there's a special bridge the platform team has made that allows it to communicate back to the main app.
  • Nick: does the main app call the SSF APIs?
  • Lynn: no it has nothing to do with the SSF APIs.
  • Nick: so they're incrementing the count in SymphonyElectron but that's not working in OpenFin.
  • Lynn: you're talking about the count in the task bar?  That's using the SSF badge count API and that's what's setting that.  It may be that the counts from apps don't count in the badge count.  On the Symphony side we call that badge count API when there's a mention, or unreads in a room or IM, or a new external connection coming in.
  • Nick: we've implemented that API, but for some reason it's not getting picked up from 3rd party apps.
  • Lynn: the 3rd party apps don't use that API.  We'd have to update...
  • Leslie: I think what Nick is saying is that when he compares SymphonyElectron to OpenFin the count is off.  Calls from the 3rd party apps need to be reflected via the SSF API.  Are you going to change that?
  • Lynn: I'll consider it - it would be a bug for the platform team.  Currently the "unreads count" does not include applications.
  • Leslie: visually they want it to the be same, which makes sense for the user.
  • Tom: leaving ssf badge counts aside, the sidebar counts are off.
  • Will: how do we make this parity?  How do we replicate this business logic for the counts?
  • Lynn: I don't think that's what anyone is saying.  If you're seeing different counts between SymphonyElectron ad OpenFin, ...
  • Tom: it was actually Minuet and OpenFin.
  • Lynn: Minuet doesn't have badge count in the task bar.
  • Tom: we're talking about the sidebar at this point - if you look under applications in the main window.  Specifically Celerity side-by-side we could see Minuet updating but OpenFin was not.
  • Lynn: that code is all in the JS side and has nothing to do with the wrapper.
  • Leslie: it doesn't sound like comparing Minuet and Electron code running in OpenFin is useful.
  • Nick: it's not a question of convenience, it's a question of what people are used to in Minuet today.
  • Leslie: this is about ensuring the Symphony app code runs well in OpenFin.  It's not about Minuet.  So when Symphony release their Electron code, it may very well be different to the Minuet code.
  • Nick: this is about surface area.  The behaviour leads us to believe that there are additional API calls from the app that doesn't exist in the SSF APIs.
  • Lynn: explain it again.
  • Tom: on the sidebar of the main window, under the application section, there's a number visible, but it doesn't get updated as new events come in on that 3rd party app.
  • Lynn: that code has nothing to do with Minuet or APIs.
  • Dov: or it could be that the container is relaxing cross-domain constraints and those apps are exploiting that.
  • Lynn: I don't know.
  • Leslie: to rephrase - if you run your electron Electron API side by side with Minuet API, you would see the app badge count change in Minuet but not in SymphonyElectron?  If so, I believe this is out of scope for this working group.  But if the behaviour is the same, then it is in scope, and we need to know more about how apps do this, so other containers can also do it.
  • Lynn: if it's not updating in the browser but is in the container, then we would want to look at at.
  • Leslie: and if it's updating in Electron and browser, but not OpenFin, then we also need to look into it.
  • Lynn: my point is that there's no SSF API involved in this, unless there's a permissions problem.
  • Leslie: let's defer this until we can test it.  I believe the test needs to be OpenFin vs Electron vs Minuet, rather than OpenFin vs Minuet.
  • Tom: ok we'll also test that on our side.
  • Leslie: was that your list?
  • Nick: yep.
  • Leslie: I'd like to add one more - if you intercept window.open you can support save & restore, but what about providing a save context and restore context API?
  • Lynn: we have that, but it's all private.
  • Leslie: so maybe that should be brought out into the public.  This is something that containers do.
  • Lynn: so when you restart the app, your pop out windows would reappear in the same locations etc.
  • Leslie: yes, and many environments have a "save layout" and "restore layout" function.
  • Lynn: right and we've implemented that in SymphonyElectron but it's all private.
  • Leslie: right, so perhaps we should bring it into the SSF API, so the container can query the app for the state, then restore that state upon request.
  • Lynn: the way it's currently implemented there's a local file that stores just the main window size & location, but then it queries back to the main app for the pop out window locations - Symphony app uses that to programmatically reopen all the windows.
  • Dov: is that in the back end, and restored across hosts?
  • Lynn: we store it in the local Symphony settings.
  • Leslie: but that's another interesting use case - to allow named layouts - "trader" etc., so it would be...A trader than moves between these saved layouts or workspaces and the set of applications (which can include other apps) are loaded and positioned. It would be good if Symphony could participate in this restore layout.
  • Nick: this would be extremely useful for us.
  • Leslie: so a proposal for you to consider is to support "getState" and "restoreState".
  • Nick: yeah and Leslie if I can add something here too - while we're really talking about creating API access to the conversation internals - we need to be able to restore state of conversations, bring them to the front, etc.  One of the things that's come up in hooking Symphony up to back end desktop workflows is to share chat context with other things on the desktop.  If we had APIs that gave us programmatic access to these things, it would allow us to create interoperability quite easily across multiple desktop apps hosted in OpenFin.
  • Lawrence: any open type of functionality would also need to be looked at from a security perspective.
  • Nick: absolutely, and OpenFin bakes this in by default.
  • Lawrence: you're talking about the container but I'm talking about the security of the Symphony app itself.
  • Dov: right - not exposing internals.  Some kind of bag of properties may be a good solution to this.
  • Nick: yeah.
  • Leslie: it'll be interesting to see on the Plexus interop piece whether they envisage making the Symphony UI interoperable through Plexus or not.  Because that's an alternative solution, and one we use in our Glue product.  This is an alternative to save & restore state, and does open up some interesting security questions.  Next week's deep dive should go into this.
  • Lawrence: we want to expose this type of functionality, but we want it to be safe.  That may mean we're not exposing it everywhere - it may be safe through some interfaces but in other interfaces we'd be concerned about XSS type attacks, for example.
  • Leslie: and this is absolutely part of the OBO use case (which I'm supposed to be writing up), to allow other apps to participate in the Symphony desktop.
  • Leslie: but going back to the first case - the container in which you're running being able to request the current state, then giving it back to you to restore - is that something that you could o do and would think about, and therefore we should specific specify it?
  • Lynn: since the app calls window.open, we have the responsibility of popping out the windows etc.
  • Leslie: right, but we want the container to be able to manage the state, hand it back to you and have you execute that logic?  So then, via this API, the user could navigate
  • Nick: there's a URI handle to specific conversations - this would be useful.
  • Lynn: symphony code has to open up the window for Symphony.
  • Leslie: 100%, but the question is whether the container can ask for that information, then hand it back when the user asks us to restore a given layout.
  • Lynn: I'd have to run it by product, but I understand
  • Lawrence: how is this data stored & passed back to Symphony?  Is there a risk of URL manipulation?
  • Dov: or we get some unique id that Symphony gives us, that's meaningless to the container.
  • Leslie: right - we just get an id, rather than the blob of window configuration data.
  • Nick: so if we just have an identifier for a user to launch a conversation or pull that user's context out of a conversation - what's the particular security concern if that identifier is accessible to the container?
  • Lawrence: the overarching statement is that we need to analyse it.
  • Leslie: we should specify this API then.  It's worth specifying, and you can analyse the proposal.
  • Nick: I think that's a great idea Leslie and we'll back it into our specification.  On the desktop you'd still be running it within the Symphony authentication context for any of this stuff ot work.
  • Leslie: Symphony needs to consider a rogue container.
  • Nick: sure, but a rogue container can scrape all URLs today anyway.
  • Lawrence: and this is what we're trying to protect against.
  • Leslie: right and this is something we discussed a while ago - whether Symphony can run in any container.
  • Nick: so I want to understand what we can do and when, and what the timeframes are on the Symphony side.  Do you have a timeframe, Laurence?
  • Lawrence: those are in the previous updates we've given.
  • Nick: I don't know of those previous updates.
  • Leslie: there's been no guarantee of integration of interop or a date.
  • Lawrence: we haven't announced a release date.
  • Leslie: and in addition there has been no commitment to even integrate with Plexus.  ... But Nick, I would recommend you share your save & restore proposal with the WG before you go to Lynn, since there are other containers that have a view on this, and it would be worth coming up with consensus from the group before we go back to the LLC.
  • Nick: absolutely - if time permits we could present it at the next WG meeting.
  • Leslie: ok.  Even an email to review is a good thing.
  • Leslie: Peter just to recap, the actions are:
    • Nick will produce a proposal for scriptable saved & restore state before the next meeting.
    • LLC will evaluate security of the proposal and raise any concerns with the group.
    • Will the Symphony UI be scriptable through Plexus interop?  This one is TBD.
  • Peter: got it!
• AOB:
  • Leslie: please attend next week's Plexus call - I think it's going to be very interesting 

Agenda

Attendees