Versions Compared

Old Version 1

changes.mady.by.user Aaron Williamson

Saved on

compared with

New Version Current

changes.mady.by.user Peter Monks

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

...

Actions items from previous meetings

  •  Jonathan Christensen: add the existing Symphony Electron container backlog & roadmap to the WG Github project.
  •  Former user (Deleted): take further comments on the charter, finalize the draft, and bring it to a vote.
  •  Former user (Deleted): coordinate with Jim regarding presenting to this WG on how desktop integration discussions can best be facilitated
  •  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
  •  Former user (Deleted): arrange a working session involving Lynn Neir, Thibaud Duprat, and engineers from the Working Group (including Colin Eberhardt (He/Him), Matthew Gardner, and Gareth Davies) to begin work on an API specification for a single feature. 
  •  Jonathan Christensen: talk to Lynn and Thibaud to encourage their active engagement with the working group and ensure that they understand the WG charter.

...

  • Minuet update
    • James Turck: A few things of interest. Minuet finally appeared in Foundation Github. Yay! We should put a link somewhere in the minutes. Not super important for us now in many ways, but may be useful and of interest to the group. Would be interested to see if someone could download and build it outside of Symphony.
    • Peter Monks: I believe the version in GH doesn’t build because proprietary DLLs have been removed.
    • Aaron Williamson: No, we onboarded the entire repository.
    • Brian Ingenito: I’ll try to build it now.
  • API specification subgroup
    • JT: Nick, can you give us an update on the API specification subgroup?
    • Nick: We’ve had two meetings that have been very productive. The results are documented on the wiki. We’ve worked through notification API and came to high level agreement about the what the parameters and shape of that should be. Now we’ll go off to do a mock implementation in OpenFin, and I believe Lynn will do that on the Electron/Symphony side. We’ll regroup every Friday for the next couple of weeks to move it forward. And we’ll look at the snapshot API next as a contrast to notifications as something with no analogue in the standard W3C world.
    • JT: Great. As a reminder for anyone who wasn’t on the last call, but if you’d like to get involved in the technical conversation about API implementation, we’ll add you to the conversation.
  • Symphony Electron Roadmap
    • JC, do you have an update on the Symphony/Electron work.
    • Jonathan Christensen: No, my job was to put Lynn together with external counterparties, and it sounds like they’re off and running and have made progress.
    • JT: I think we might be interested in what your roadmap looks like for migrating from Minuet to Electron.
    • JC: Haven’t defined a timeline for when we’ll cut over, but internally we’ll start using it against our corporate environment as soon as Lynn points us to some builds with some basic stuff implemented.
    • JT: As those plans mature, there are some milestones which we could agree that in order for the API subgroup’s outputs to work, we’ll need to know Symphony’s plans. For example, to define the HTML5 application that is Symphony so that people can get ahold of that and put it in a compatible container. Can we talk offline about what those steps are and how to put them into your overall plan?
    • JC: Makes sense. There’ll be plenty of warning. We’ll have a beta program with some customers to test out the new container out in advance, but we’re a couple of sprints away from being able to talk about the timeline.
    • JT: Ok. Any other questions for JC while he’s on the line? Ok, probably the only other item on the agenda is the charter discussion?
  • API specification
    • Gareth Davies: Just going back to the APIs, I know we passed the spec. Can we send that around so everyone can see how we’ve designed and shaped it, to make sure that everyone can see it and that we’re on the right path?
    • JT: Agree, can’t recall if we said at the last meeting whether we felt that we had was sufficient or whether we wanted one last meeting before we sent it out to this group, but obviously we should be sharing the work with this group as it progresses.
    • GD: I think we should share it as we go for transparency so we’re not presenting anything as complete, so everyone feels welcome to give input. We should also schedule a demo soon. I touched based with Colin today and he showed me a neat little demo he’d done, just having worked off our spec. It was nice to see something real.
  • API specification prototype implementations
    • Colin Eberhardt: The rough API that we’ve outlined is all on the Symphony Confluence, so it’s all out in the open. The only thing I’ve done is put together a little prototype implementation based on that API that I was going to share with the subgroup on Friday.
    • JT: We’ll crosslink in to the meeting minutes.
    • CE: The implementation only exists on my laptop at the moment, but I’ll put it in Github so we can discuss it on Friday.
    • GD: Would like to get these prototypes into the Foundation codebase so everyone can see.
    • JT: We could create a DW WG prototypes project to put these into—maybe just one project to put various small pieces into.
    • Peter: Absolutely.
    • JT: Anything going into Symphony Electon, we should talk about who the project lead is on that, don’t know who it is on Github at the moment.
    • PM: It’s Lynn Neir for both Minuet and Symphony Electron. Would encourage folks to submit pull requests, which doesn’t require permissions.
    • GD: How would that work? These are just demonstrations of a possible implementation, not the proposed final implementation.
    • JT: Could just do it on a fork.
    • GD: Do we need to set up a CCLA for this up front so that we can collaborate more easily?
    • JT: Yes, to contribute to a Foundation project you’ll need CCLAs and Github access.
    • PM: In your case, Colin, Might be an ICLA.
    • CE: I’ll do it in my personal GH at first till we get an ICLA in place. I’d still want to have commit access.
    • PM: That’s the way Foundation projects work—you would retain admin rights, we just host the repo.
    • JT: Colin, could you and Nick work with Peter and Aaron to get the project set up? Then I’ll get it approved in ESCo, and we’ll get everyone working together.
    • Nick: Colin, I’d love to see the implementation too.
    • JT: I’ll propose that at the next WG meeting, we go through the output of the subgroup and any demos that are available then. I’ll be on holiday, so can someone step up and be the chair? (March 8)
    • Nick: I can do it.
    • JT: Any other questions about practical working group? I’m super pleased with the progress. I know there will be organizational stuff between here and proving we can get Symphony running in a real container, but I’m glad to see how things are going.
  • Symphony stream URI support for desktop app interop
    • JS: It’s great that we might have people building multiple wrappers. I’d like to get a sense of whether the Symphony URI introduced maybe in version 1.4.1, so you can call it from any other Windows application and call up a stream and get that stream in focus--in general, is that something people think you’ll be using if you build your own wrappers? Should we think about making it a standard you need to support, to facilitate interoperability with other apps on the desktop?
    • PM: Does this relate to the interbank interop WG that DB has proposed?
    • JT: It does, but it’s specific to the desktop. Johan, are people relying on the URI at the moment?
    • JS: Our plan at FactSet is to use the URI of a stream to focus on a conversation when the user gets something back from our product.
    • JT: If people are using it, and 3rd party apps are using it, we should definitely think about making it a requirement that wrappers support it. If it’s not, then it becomes a much less useful capability for a third party provider. My suggestion: put it on the list of capabilities as a candidate for container support requirements. Then we can bring it up to this group for discussion.
    • JS: sounds good.
    • JT: so it goes into our list along with the Javascript API – external URI implementation.
  • WG charter
    • Last thing on list: the charter. More or less in same form as last time in meeting notes. Items 1 & 2 we’re mostly happy with, on 3 there’s a potential dependency on conversation re: interop WG. Maybe change 3 to refer to potential other WG. Would like to move to a vote since I’ve had no substantive feedback in several weeks. I’ll edit 3 as mentioned so we can move to a vote. Focus on interop for this WG will be on desktop only.
    • Nick: Was there supposed to be a presentation from DB on their interop tech, or did that get pushed off, or was I misremembering.
    • JT: I spoke to DB a couple weeks ago, and they weren’t ready to do that yet. Slava?
    • Slava Kryukov: That’s right, we want to work out a couple of things before presenting to the group, but it’s certainly a priority for us.
    • BI: Both Nick and I could make Minuet build and run a sample app.
    • JT: Now that people are able to build Minuet, if people interested in doing any work on it, I’d be interested in finding that out.
  • [Adjourned.]

Action items

James: A few things of interest. Minuet finally appeared in Foundation Github. Yay! We should put a link somewhere in the minutes. Not super important for us now in many ways, but may be useful and of interest to the group. Would be interested to see if someone could download and build it outside of Symphony.

 

Peter: I believe the version in GH doesn’t build because proprietary DLLs have been removed.

 

Aaron: No, we onboarded the entire repository.

 

Brian: I’ll try to build it now.

 

JT: Nick, can you give us an update on the API specification subgroup?

 

Nick: We’ve had two meetings that have been very productive. The results are documented on the wiki. We’ve worked through notification API and came to high level agreement about the what the parameters and shape of that should be. Now we’ll go off to do a mock implementation in OpenFin, and I believe Lynn will do that on the Electron/Symphony side. We’ll regroup every Friday for the next couple of weeks to move it forward. And we’ll look at the snapshot API next as a contrast to notifications as something with no analogue in the standard W3C world.

 

James: Great. As a reminder for anyone who wasn’t on the last call, but if you’d like to get involved in the technical conversation about API implementation, we’ll add you to the conversation. JC, do you have an update on the Symphony/Electron work.

 

JC: No, my job was to put Lynn together with external counterparties, and it sounds like they’re off and running and have made progress.

 

JT: I think we might be interested in what your roadmap looks like for migrating from Minuet to Electron.

 

JC: Haven’t defined a timeline for when we’ll cut over, but internally we’ll start using it against our corporate environment as soon as Lynn points us to some builds with some basic stuff implemented.

 

JT: As those plans mature, there are some milestones which we could agree that in order for the API subgroup’s outputs to work, we’ll need to know Symphony’s plans. For example, to define the HTML5 application that is Symphony so that people can get ahold of that and put it in a compatible container. Can we talk offline about what those steps are and how to put them into your overall plan?

 

JC: Makes sense. There’ll be plenty of warning. We’ll have a beta program with some customers to test out the new container out in advance, but we’re a couple of sprints away from being able to talk about the timeline.

 

JT: Ok. Any other questions for JC while he’s on the line? Ok, probably the only other item on the agenda is the charter discussion?

 

GD: Just going back to the APIs, I know we passed the spec. Can we send that around so everyone can see how we’ve designed and shaped it, to make sure that everyone can see it and that we’re on the right path?

 

JT: Agree, can’t recall if we said at the last meeting whether we felt that we had was sufficient or whether we wanted one last meeting before we sent it out to this group, but obviously we should be sharing the work with this group as it progresses.

 

GD: I think we should share it as we go for transparency so we’re not presenting anything as complete, so everyone feels welcome to give input. We should also schedule a demo soon. I touched based with Colin today and he showed me a neat little demo he’d done, just having worked off our spec. It was nice to see something real.

 

Colin: The rough API that we’ve outlined is all on the Symphony Confluence, so it’s all out in the open. The only thing I’ve done is put together a little prototype implementation based on that API that I was going to share with the subgroup on Friday.

 

JT: We’ll crosslink in to the meeting minutes.

 

CE: The implementation only exists on my laptop at the moment, but I’ll put it in Github so we can discuss it on Friday.

 

GD: Would like to get these prototypes into the Foundation codebase so everyone can see.

 

JT: We could create a DW WG prototypes project to put these into—maybe just one project to put various small pieces into.

 

Peter: Absolutely.

 

JT: Anything going into Symphony Electon, we should talk about who the project lead is on that, don’t know who it is on Github at the moment.

 

PM: It’s Lynn Neir for both Minuet and Symphony Electron. Would encourage folks to submit pull requests, which doesn’t require permissions.

 

GD: How would that work? These are just demonstrations of a possible implementation, not the proposed final implementation.

 

JT: Could just do it on a fork.

 

GD: Do we need to set up a CCLA for this up front so that we can collaborate more easily?

 

JT: Yes, to contribute to a Foundation project you’ll need CCLAs and Github access.

 

PM: In your case, Colin, Might be an ICLA.

 

CE: I’ll do it in my personal GH at first till we get an ICLA in place. I’d still want to have commit access.

 

PM: That’s the way Foundation projects work—you would retain admin rights, we just host the repo.

 

JT: Colin, could you and Nick work with Peter and Aaron to get the project set up? Then I’ll get it approved in ESCo, and we’ll get everyone working together.

 

Nick: Colin, I’d love to see the implementation too.

 

JT: I’ll propose that at the next WG meeting, we go through the output of the subgroup and any demos that are available then. I’ll be on holiday, so can someone step up and be the chair? (March 8)

 

Nick: I can do it.

 

JT: Any other questions about practical working group? I’m super pleased with the progress. I know there will be organizational stuff between here and proving we can get Symphony running in a real container, but I’m glad to see how things are going.

 

JS: It’s great that we might have people building multiple wrappers. I’d like to get a sense of whether the Symphony URI introduced maybe in version 1.4.1, so you can call it from any other Windows application and call up a stream and get that stream in focus--in general, is that something people think you’ll be using if you build your own wrappers? Should we think about making it a standard you need to support, to facilitate interoperability with other apps on the desktop?

 

PM: Does this relate to the interbank interop WG that DB has proposed?

 

JT: It does, but it’s specific to the desktop. Johan, are people relying on the URI at the moment?

 

JS: Our plan at FactSet is to use the URI of a stream to focus on a conversation when the user gets something back from our product.

 

JT: If people are using it, and 3rd party apps are using it, we should definitely think about making it a requirement that wrappers support it. If it’s not, then it becomes a much less useful capability for a third party provider. My suggestion: put it on the list of capabilities as a candidate for container support requirements. Then we can bring it up to this group for discussion.

 

JS: sounds good.

 

JT: so it goes into our list along with the Javascript API – external URI implementation.

 

Last thing on list: charter. More or less in same form as last time in meeting notes. Items 1 & 2 we’re mostly happy with, on 3 there’s a potential dependency on conversation re: interop WG. Maybe change 3 to refer to potential other WG. Would like to move to a vote since I’ve had no substantive feedback in several weeks. I’ll edit 3 as mentioned so we can move to a vote. Focus on interop for this WG will be on desktop only.

 

Nick: Was there supposed to be a presentation from DB on their interop tech, or did that get pushed off, or was I misremembering.

 

JT: I spoke to DB a couple weeks ago, and they weren’t ready to do that yet. Slava?

 

Slava: That’s right, we want to work out a couple of things before presenting to the group, but it’s certainly a priority for us.

 

BI: Both Nick and I could make Minuet build and run a sample app.

 

JT: Now that people are able to build Minuet, if people interested in doing any work on it, I’d be interested in finding that out.

 

[Adjourned.]