Table of Contents

Date

18 Oct 2017

Action items

Add new action items here.

Meeting notes

NK: More APIs should be behind the SSF namespace because it’s not Polyfill.

LN: It’s currently behind the namespace, modeled on the Notifications API but with the possibility of adding extensions.

WQ: Is there an item on key use cases we have to facilitate via the API?

LS: There's no formal set in the wiki.

NK: That’s a great question, we haven’t focused on that yet and we’ve been focused on parity with the Minuet container. It’s been hard on our side to get an evaluation of feature parity on our side. So I think that’s a great thing to put on the agenda.

AW: Is there any functionality needed in the HTML5 app's API that's not currently provided?

NK: The one I’m most aware of is the ability to start a chat with a user from another application.

BI: If you’re running a container, you could pass a message from the UI of another app into Symphony.

LN: I think the path going forward is Plexus, which would facilitate that kind of action in the future.

NK: I’m just thinking from the client experience perspective. If there’s a definition of the top data item coming across that pipe that the client would read, is that implemented?

LN: No, not currently. There’s a protocol handler that we’ve added on, but it’s not part of the API. You can open up a chat from an external app.

SK: I’ve found that to be limiting, it’s quite sluggish.

LM: We felt that it didn’t make sense to continue developing this kind of interactivity, so we think the appropriate path forward is Plexus or something like it. There are also backend APIs that can be used to trigger those kinds of things.

NK: Totally agree with you on the security issues, Lawrence. Are you aware of what Plexus does in that area?

LM: We’ve started to discuss it with DB, but we’re still working it out.

DK: How is OpenFin handling this?

NK: We’re using a verifiable service outside the app, then a token exchange that can be verified by the bus, then use kind of an HTTPS model to say the connection is verified, then leave it up to the endpoints to decide who they want to talk to based on the verified identity. The other thing that’s there today is the ability to send messages.

SK: A suggestion. Do you think it would be worth it to have a separate session with a detailed presentation of Plexus, how it works, and how the security system works.

AW: Lets do that as a webinar. Ok?

SK: Sounds good to me.

DK: Are you thinking at all about protocol handling within the handler, to make it possible for Symphony componentry to do things within Symphony?

LM: One consideration is that we’d like to have the application work in a generic HTML container environment, so we’re more likely to build those things using standard HTML containers.

LM: We’ve worked on that with some of our partner/terminal integrations like with Thomson Reuters, but they’re using different Symphony APIs.

NK: This is something we’re interested in as well. [requiring user to be authenticated…] We use similar protocols to do things within OpenFin today. We wouldn’t want to make a Symphony protocol handler and we don’t have a way to enable apps to write their own protocol handlers, but we’re looking at how that would work. But it would help to know whether this is something you intend to support in the future.

LM: I think it depends on what happens with Plexus and where that fits in. There’s no specific timeframe yet.

NK: Is the electron app supporting the protocol handers today?

LN: Yes.

AW: Other use cases.

DK: Global keyboard shortcuts.

LN: You mean when you’re outside Symphony?

DK: Yeah, like when I want to advertise global keyboard shortcuts out to the operating system, how I’d do that.i

LN: That’s not supported now, but it’s an interesting use case.

WQ: Is there a menu of available functionality now?

LM: It’s on the developer website.

DK: Is there a list of recent API changes? I’ve found it hard to find that without just scrolling through it all.

LN: For the wrapper, there’s nothing public.

LM: Dov, we previously sent out email notifications to people who had registered on the site, but had feedback that customers wanted us to go through the usual change management process.

DK: It would be good to have that as an opt-in notice.

LM: It was opt-in.

DK: The reason we’re interested in this is that knowing about new features would spur ideas about what we could do with it. But if we have to troll through it we’re less likely to learn about those things.

WQ: We’d be interested in that as well.

NK: Yeah, and I think there are a lot of possibilities here, we just need to figure out how to understand which new APIs might not last long or might be rolled into others.

AW: undocumented API issues.

NK: There’s only one API that stands out, which is RegisterLogger – I don’t think it belongs in the definition. The only issue is that the web app would break if it wasn’t stubbed out.

LN: We fixed that in our latest release 48 which should be out now.

NK: How do we know when these things roll forward, what’s in that release, what’s changing, etc.? I’ll also add that there’s one other issue we’re looking at, which is that we need to get better visibility into rules by which notifications are pushed. It looks like there are some gaps regarding how window state affects when notifications get pushed.

LN: That’s our internal implementation in JavaScript – you don’t get a notification if the window’s in focus. That has nothing to do with the wrapper.

NK: You’re just using the browser focus() method to check that, nothing specific to Symphony?

LN: No. We know when a chat window is in focus and don’t even put a notification out to the API. If you’re not seeing that behavior, that’s a bug and we can discuss that.

NK: How will developers relying on these APIs get notifications of upcoming changes so they can support them? And should we convene a group to work on the ongoing maintenance and growth of that API, and just people with skin in the game on the APIs.

WQ: That really seems like this group.

LM: I’d agree, and if there are items that we don’t want to focus on in these meetings, we should agree on a side-channel.

NK: I think this group should take on the question of the rules for protocol handlers and whether needs to be any kind of standardization.

MG: This is the same conversation we’ve been having year-in and year-out.

DK: And now the difference is that there is an open source client for the API.

LM: And we have Plexus contributed which will provide some of that functionality.

LN: We’re already publishing what’s currently supported and the only thing I’m aware that might change is that Plexus will be available to integrate with the container.

LM: We haven’t set a plan with end-of-life dates for any of that, but we’ll share it as soon as we do.

NK: What would be great is if we could have a better view of even the shorter-term roadmap for the webapp and the electron part. And leaving aside Plexus, just understanding even stuff like that the logger API was dropped in 48 – I only learned about that in the context of this group, but there should be a mechanism for telling people consuming these APIs that those things are coming, and to give us some ability to provide feedback on those things.

LN: It’s visible in Github, but maybe we could make that stuff available in Jira or Github.

NK: That’s what we do at OpenFin, we use GitHub for this—issues, the wiki, and comments.

LN: We do all of that.

NK: The tricky thing for me is that a lot of the information is not relevant, so I’d need to pick out the relevant information.

AW: Please let me know the most useful format for that information and we’ll try to figure out how best to get that to the community.

Agenda

Attendees