...
- 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!)
...