2016-07-13 Meeting Agenda / Notes

Date

Jul 13, 2016

Attendees

Notes from Previous Meeting

• Discussed potential for Minuet to move to Electron in the future - need to session to discuss

• Suggestion for a potential future project to bridge the electron C extensions to Java, .Net etc

• Symphony API requirements - New Window, Notification, IPC (Websocket bus), Extensibility (Native libs)

Action Items from Previous Meeting

Meeting Notes

• Minuet open sourcing:

  • Still awaiting signed CCLA from Goldman Sachs

  • Discussion of which code base should be open sourced - currently there are two forks:

    • Goldman Sachs (contains 6 months worth of bug fixes that aren't in the Symphony LLC fork)

    • Symphony LLC (contains some enhancements that aren't in the GS fork)

  • The Foundation's intent is to consolidate 

• Existing requirements & comparison documents:

  • Goldman has some internal documents, but they can't be shared verbatim

    • Would need an NDA

  • Question: will Minuet converge towards Electron or not?  Bigger picture question: what do we think 

  • Goldman perspective:

    • C# based solution has been really good to date, but now is the time to pivot to Electron or OpenFin

    • Lots of complexity in supporting it, not cross-platform

    • Some complex stuff that may be difficult to port, but it's been overtaken

    • In terms of OpenFin vs Electron, OpenFin v6 is an Electron app anyway, and their open source framework may be "good enough" (with those interested able to purchase the more fully featured commercial version)

    • Electron is the market leader - whatever we look at should use Electron at the core

    • But Electron has some pretty serious security holes in it (e.g. sandbox) - OpenFin have had to disable some of this

  • Should this group be making a public statement around Electron being the market leader?

    • Gareth: I think that's Goldman's conclusion - that whatever we choose should be based on Electron

    • In which case, should that statement actually be based on an OpenFin overlay?  It's close to what would have to be done anyway.

  • Had an existing conversation with Colin Eberhardt from "ScottLogic"

    • Seemed to be pretty strong in Javascript, Electron etc.

    • Colin recently spoke at a conference in London and was pretty impressive

  • Perhaps there's an option to use vanilla, insecure Electron, and then hardening for production use is a choice for the user?

    • There are common security elements that would require need to be addressed by everyone, so perhaps an "Open Core" OpenFin wrapper would be a better choice

  • @WilliamS: moving away from a model where we're dependent on one vendor and instead promote an open-source, standard, secure container for FinTech

  • What is the MVP for a framework?

    • Vanilla electron?

    • Electron + security?

    • Electron + language bindings?

    • Capability mechanisms (to support variation between container implementations / editions)?

  • Longer term, Electron will inevitably lose its lustre, and this group could / should be ahead of the next generation of container technology

• OpenFin has just joined the Foundation as a Community Member - should we bring them into this WG?

  • Group: Yes

Discussion items

Action items