2016-07-27 Meeting Agenda / Notes

Date

Jul 27, 2016

Attendees

Agenda

Previous Action Items

From Earlier Meetings

From Last Meeting

Meeting Notes

• Introducing Nick Kolba from OpenFin

  • Formerly ICON architect at Thomson Reuters

• Minuet open sourcing

  • Still awaiting final legal approval from GS

• Charter discussion

  • @Former user (Deleted) - @WilliamS was saying that Minuet could be advanced by embedding Electron within it

  • @Former user (Deleted) if there were docs / source code for Minuet, I could compare it to other containers we've been evaluating

    • But right now I don't have anything

    • I don't know how Minuet interacts within Symphony

  • Containers tend to have markedly different development approaches.  Building an Electron app, for example, is not like building a web app.

  • The real value proposition of a container is being able to leverage native platform capabilities

  • "We should be careful how far we want to push the rock of standardisation and platform / container independence."

    • There are some fundamental differences between platforms that can't be abstracted away e.g. window management on Windows vs iOS

  • "The key is an extensibility framework - having a mechanism to allow developers to develop low-level plugins that can be exposed up to the JS app layer."

    • Symphony's plugins (desktop-native notifications, end-to-end encryption) are good examples of these plugins

    • It also allows fallbacks e.g. for older platforms

    • You can't make everyone happy with pre-built capabilities, but extensibility offers a "choose your own adventure" path - offers flexibility for developers to make a choice

    • This is two things:

      • Extensibility of the container itself via low-level plugins

      • APIs that expose those low level capabilities up to the JS / UI layer

    • @Rob Koyfman the embedding API provides some of this

    • @Former user (Deleted) aren't we trying to identify the capabilities that the container will provide?

      • e.g. security, messaging

      • Need to understand what those core capabilities are, allowing code to introspect them

      • Base container ("the browser") plus additional capabilities for desktop wrapper

    • @Peter Monks I see semi-independent 3 layers:

      • Extensibility / plugin model - the specifics of how new native code can be injected into the container

      • Discoverability around those plugins - the specifics of how app code discovers these plugins and their capabilities

      • Semantics around discoverability - (the hardest problem) the specifics of how app code can avoid "guessing" what capabilities mean, and be able to leverage new, previously unknown plugins

    • Features that Symphony explicitly extends the platform with:

      • Screen capture

      • Notifications

      • Native encryption

      • Shortcut keys

      • Windowing (locations, sizes, chromeless / skinned windows, etc.)

      • Base capabilities:

        • Security (whitelisted sites)

        • Message bus

  • How does OpenFin handle extensibility and feature discovery?

    • We take a very web-centric view on app development.  99% of the code should be web code.

    • Leverage OpenFin to do what's not possible via web standards.

      • These are all async callbacks, so if something isn't supported the app code has recourse.

    • The intent it that the app would also have its own wrapper, and handle unsupported callbacks, so that if that code is not running in OpenFin (e.g. in a browser) it still functions.  An example might be opening windows, where OpenFin offers more variations (chromeless / modal windows) than browsers.

    • This is the same model ICON used.

    • This model allows fallback capabilities to be implemented via standard browser mechanisms, where possible.

    • OpenFin offers discoverability via a message bus - messages are not predefined.

    • Discoverability could be implemented on top of that, but it's not core to OpenFin.

    • For OpenFin itself, we mostly provide tooling.  We don't support discoverability - we don't have a directory as part of our solution.

  • Two ways to come at this:

    • From the framework "up", with Symphony one example (of potentially) many apps

    • From Symphony "down", with the platform focused on fulfilling Symphony's needs first
      
      

• <Ran out of time to discuss ScottLogic - will add to next meeting's agenda>

New Action items