Versions Compared

Key

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

...

  • 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

...