...

Date

22 Mar 05 Apr 2017

Attendees

Actions items from previous meetings

...

Meeting notes

Revised Charter

James Turck: Update on revised charter. If there was higher attendance we could have done a vote. Short version is, we’re talking about bullet point 3, interoperability, because of the conversation with DB. Since that may take some time, I suggest we go ahead without charter until that becomes a thing. I’ll share the charter after the meeting and put together a vote. Any questions?

API Specification Subgroup Progress

James Turck: Nick Kolba asked me for some clarity on where we were going on the subgroup re: specification of the API. I had responded to that group that we would try to reach agreement on that here. Nick and Colin, would you like to take us through the discussion points?

Nick Kolba: Sure. We’ve been doing good work in the subgroup. Started as writing code as a way of discovery the shape of what needs to be covered. My understanding was always that we should deliver a specification that the LLC would be the implementers of on the client side. Then any container maker could meet that interface and wrap Symphony. I wrote a proposal last week to try to steer the group back toward that objective, because I felt like we were getting into territory best left to the LLC and its web application, or to the container-maker. I think we should leave as much latitude as possible on either side of the interface for either implementer to bring their opinions to the table.

Proposal: messaging layer that is the interface between the web app and any container. Web app would be responsible for creating any Javascript API it wants over that layer. The container would create its own bindings that it would inject into the app via preload scripts or includes, that’s immaterial to the spec. Then the container could fulfill the interface however it sees fit via IPC. That spec circulated with the subgroup, James has seen it, so has Mazy and some others. Just wanted to get feedback on that. Final point: it’s become pretty clear in conversations with Lynn that it’s got to be up to the LLC to implement that API. They know what events & functionality they need and I don’t have a strong opinion about how they structure that. Most important thing is that they expose an API that other containers can bind to and is consistently maintained.

Colin Eberhardt: At ScottLogic, we’ve been doing closely related things. Originally started by creating Javascript API for these containers, like what Brian and Lynn have been doing. Agree it’s up to the LLC to create the interface. Our idea was we could implement this and open source it, which is why we started the process to contribute it.

James Turck: Two things: key outcome for success looks like being able to host Symphony in multiple containers, which requires concrete API exposing capabilities in standardized way. I’m not axed on the method, but I am on our charter, which says that’s what would be the outcome. I believed we had a commitment from Symphony on that. I prefer to split the implementation from that pure point of what we’re looking for from Symphony as an outcome.

Nick Kolba: Totally agree on that success criterion. What it comes down to is: What is the packaging of this that will move the needle and is something the LLC can work with? Interesting thing about this process is what it shows is that the LLC structurally cannot adopt this code being made by ScottLogic, because to make that binding/shim layer, you basically need to build a container. They have two choices: expose another API to be able to configure that container so container maker can decide how it should behave, which means you’re just moving the problem into another layer. There’s not much point in a container provider doing that. So it became clear that the only solution is to produce a spec that’s open enough that the LLC can work with it, that can get them part of the way there and can fulfill that spec however they see fit. What is the lowest common denominator that they can commit to?

Colin Eberhardt: James, my interest is more in doing something more grand that just running Symphony in multiple containers, why not create a complete abstraction layer? Is that a conflicting or compatible aim?

James Turck: I see it as compatible, and potentially a Step 2. We’ve had this conversation on and off and the idea was, if we can prove that we can make it work for Symphony, you could work off that to create a standardized abstraction layer that would work between any app and any container.

Colin Eberhardt: Ok, just wanted to make sure it was compatible, don’t want to hijack the process.

James Turck: As a use case to getting to the grander vision, hopefully you agree that getting it to work for Symphony is a step one. That’s the main interest of many of the members here.

Colin Eberhardt: Good to hear.

Mazy Dar: I have to strongly disagree, it’s not my understanding that this WG is meant to be abstracting containers. We’ve been talking exclusively about getting Symphony to run in any container. I think getting into something that’s really a distraction is slowing us down from getting there.

James Turck: I’ve been around longer and it’s certainly been discussed, though it’s not job one.

Mazy Dar: Then it would be helpful to have the members here express that, because I haven’t heard that.

Peter Monks: As a point of process, the second objective in the original charter is what James just said. The primary objective was to shepherd Minuet, which has fallen by the wayside. Correct James?

James Turck: Essentially yes.

Mazy Dar: There’s a huge difference between creating an abstraction to get Symphony to run in multiple containers and trying to abstract the idea of a container.

Nick Kolba: agree. There’s been talk of this subject, and it’s tantalizing to think that we could get there if we can do it for Symphony. There are definitely standard workflows that can be abstracted out to others. But we are talking about a much larger topic if we go there. I think it’s distracting us from the work we really need to do now, which is to make Symphony able to run in multiple containers.

James Turck: You’ll have to excuse my ignorance but I don’t see them as incompatible, but I guess that’s part of the work we have to do.

Nick Kolba: Not incompatible, just a distraction at this stage.

Colin Eberhardt: That’s part of the reason I’ve said we should put our contribution on hold. And I’m on the fence myself.

Peter Monks: And as I said in the comment, we encourage working through those issues in public. I get the concern about putting out code that’s going to get scrapped…

Colin Eberhardt: My concern is more with distracting this WG’s effort.

Peter Monks: That’s a question that should be worked out in the open during the contribution process. The ESCo has already approved the contribution, which means they’ve already decided it’s an appropriate contribution.

James Turck: Yes, but that’s only a decision that the contribution is generally in keeping with the Foundation’s mission. The question Colin is talking about is whether it’s the appropriate direction for this working group.

Colin Eberhardt: Right, and I’m not going to push the button till the working group says they’re ok with it. I want the group to be happy with the direction.

Mazy Dar: I just want everyone to know where we’re coming from. The charter says the point is to drive standardization across FinServ such that apps such as Symphony can run in different containers. Every frim with a container has their own way of doing common tasks. This is an enormous topic that multiple banks are working on. The idea that this group could create an abstraction that makes that go away is not possible. We could never get there and it would be a massive distraction. We’ve been showing up with the goal of getting something working to see something of value come out of the Foundation.

Mazy Dar: LLC is already defining these things their own way and we’ll be chasing those for some time. But if we approach these things as we’ve described, then each bank/container can figure out what to do with that. Then we just have to build a little bridge to what Symphony says they’re building, to pass events on to different containers to let them figure out how to handle them.

James Turck: No question that that’s a solution to this. Not sure what the disagreement is here. The draft new charter is not in any way incompatible with either of these goals. But if the working group wants to change the charter, they can.

Mazy Dar: We’ll definitely suggest that change, to focus on this as the top priority. When it comes to the idea of getting Symphony-based apps to work in multiple containers, it’s the same solution. Requires LLC to have a simple way to expose their functionality to…

Colin Eberhardt: What do you mean by Symphony-based applications?

Mazy Dar: As I understand it, LLC has an application framework and there are apps running within Symphony, like Selerity, ChartIQ, etc., and it’s those apps that the charter is focused on this working group supporting.

James Turck: I get the cynicism that a greater abstraction is not something we can do via the Foundation, but that was the original idea.

Nick Kolba: What I think is really key here is that it’s physically impossible to create a way to abstract this across all containers. If we tried to create a library that was distributed that all containers had to use to interoperate, it’d be DOA.

AS: I agree that’s true if you’re trying to provide 100% coverage for all container functionality, but if you’re trying to provide a MVP for simple functionality that’s fundamental across containers, this is something MS is really interested in doing. We’re massive supporters of OpenFin, but we see this something that’s worth approaching and is doable for a MVP. IF you don’t have a lot of options for your target containers, I think this is worth doing and possible.

Nick Kolba: I think where ScottLogic’s code runs into a problem is, once you try to get it implemented in Symphony, it’s going to start having to express opinions because of how it’s structured. Look at W3C. It’s a spec of an API that various apps meet on the web app and browser side, and I can’t imagine it working any other way.

James Turck: But that was absolutely the intent when we started. We asked whether the W3C spec was sufficient and said if it’s not we need to extend it. The concrete implementation is up to whoever makes the container.

Colin Eberhardt: I see our code as a reference implementation that proves the validity of the specification.

Nick Kolba: But we don’t have a spec, so I don’t see how we can have a reference implementation.

Colin Eberhardt: I agree, let’s do the spec – our work can be adapted to any spec.

AS: I agree with that approach.

Nick Kolba: I have no doubt, but I don’t think it can be done by giving people a library. Anyway, whether it’s message-based or based on an API spec, I’m not very opinionated. I proposed message-based model because I’ve seen it work and it works well with the browser and the bindings. But I think the underlying question is, what is the overall goal of this working group – to get Symphony to work in various containers, or to create some generic spec?

James Turck: As I’ve said, I’m happy for the Symphony goal to be our top priority, but I don’t see these as incompatible.

Nick Kolba: Fine with me as long as we ruthlessly control the scope. It’s hard to get the LLC to move. And I’m concerned because I’ve seen the WG do this before, move on from the necessary thing to the thing we can make movement on. And I don’t want to get distracted from the most important task.

James Turck: I agree that we need to get LLC on the call or escalate to Lawrence – we’re making a spec, are you committed to implementing it? I thought they’d committed already but if that’s drifted, we need to revisit it.

GB: We should raise this at the April board meeting.

James Turck: Yes. I’ll need input from people who have attended the subgroup on what LLC has been saying.

Nick Kolba: Lynn has been on the calls and has expressed the view that LLC has no plans to adopt what’s currently being done in the subgroup, because of deadline pressure and there not being a spec. But I don’t care what Lynn does, just want JC/the web app does. He’s the right person to talk to and we need to understand from them what works for them, because that’s what’s missing. No point to keep working on this if they’re not going to adopt it.

Colin Eberhardt: What I understand is that he’s implementing a spec himself, which is confusing.

Nick Kolba: If Lynn could just share whatever spec he’s working against and they could make some guarantee of some basic stability and that they’ll keep us apprised of any changes, I can work with that.

James Turck: So what’s the action?

Nick Kolba: We need to make the mandate that the LLC shares its spec with us and how they want to communicate that…

James Turck: I don’t want them to just be driving here.

Nick Kolba: Whether we like it or not they hold the keys.

James Turck: True but the idea was for there to be some level of collaboration.

Nick Kolba: But we should get them to publish what they have today.

James Turck: If they do that it’s already too late for changes, but I get your point that we have to start somewhere.

Nick Kolba: Gareth knows a lot about it, circa Minuet days, but it’s a moving target and we need a channel for sharing information on updates.

James Turck: Can we put down specifically what we want from the LLC, so we can send that off to JC, Lawrence, and Lynn and get some agreement?

Nick Kolba: I can do that.

James Turck: Ok, please put it in the wiki and everyone weigh in, and we’ll send it off. I think we all agree that we need more engagement form the LLC.

Nick Kolba: Peter or James could you tell me where this should go?

Peter Monks: Don’t worry, just create it and send me the link and I’ll put it wherever it should go.

Action items

•  Former user (Deleted): put a clear description in Confluence of what information and cooperation the Working Group needs from Symphony LLC to make progress.
  
  •  All: review and comment on Nick's description
•  Former user (Deleted): bring the issue to the ESCo at next week's meeting
•  Former user (Deleted) and Former user (Deleted): prepare a briefing for the April 19 board meeting
•  Mazy Dar: propose revisions to the draft charter to narrow WG's mandate