Date

27 Jul 2016

Attendees

Agenda

Previous Action Items

From Earlier Meetings

• Former user (Deleted): schedule session to review APIs
• Former user (Deleted): schedule discussion on future plans and how we manage contributions plus major design decisions (like a move to Electron). We should discuss future support arrangements, i.e. we shouldn't all need to make the same security patch.

From Last Meeting

• Peter Monks to introduce OpenFin folks to the Desktop Wrapper WG, and request their participation
• Former user (Deleted) to introduce Colin Eberhardt (ScottLogic) to Peter Monks (peter@symphony.foundation)
  • Peter Monks to give Colin an overview of the platform and Foundation, if he's interested
  • Peter Monks to introduce Colin to Symphony LLC BD/partnerships team
• WilliamS to coordinate a review of the current WG charter (with assistance from any/all interested WG members), and proposed changes will be presented back to the WG at a future 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

• Gareth Davies and Former user (Deleted) to catch up for coffee and discuss the Minuet discoverability API (please confirm that I captured this action accurately!)