Closed jonnor closed 10 years ago
There are two separate use cases for the runtime registry, both of which should be considered:
The runtime registry is a web service provided by Flowhub. Runtimes can register themselves there so that they become visible in user's NoFlo UI.
We collect the following information for each runtime:
id
: UUID identifying the runtime instance (web page, Node.js server, specific MicroFlo device)user
: The Grid user owning the runtimeaddress
: URL for the runtime protocolprotocol
: protocol identifier (iframe
, websocket
, webrtc
, etc)type
: type of the runtime (noflo
, microflo
, etc)label
: optional textual name for the runtime instancedescription
: optional longer textual description for the runtime instancesecret
: optional secret string client must use to connect to the runtimeAdditionally we track the time the runtime has been last seen. Runtimes can "ping" the registry to know they're still alive.
With the Flowhub Registry library it is now easy to register and list runtimes.
Now we need easy explanation how to register the typical runtime types (NoFlo on Node.js, MicroFlo), and then we can start caching components here, as well as replace the old runtime address handler in the graph view:
Initial implementation in MicroFlo: https://github.com/jonnor/microflo/commit/92ccf0827677675b1afa37749e369f268d5af5a2
For Node.js runtimes, we have a helper called noflo-nodejs for setting up and running server-side NoFlo runtimes so that they communicate with Flowhub.
We now have a simple info popup on how to register runtimes:
And now connection settings are handled by selecting a runtime:
NoFlo UI / Flowhub can communicate with several different runtimes, but currently one has to specify which in form of an URL. Runtimes should instead be able to register themselves dynamically with Flowhub.
This should also enable users to use a central Flowhub instance with their own custom runtime instances (possibly on/with specialized hardware, and on a private network).
It should be easy to host ones own registry in combination with a Flowhub UI. It should be possible to change the registry to connect to, both systemwide and for one specific runtime (std precedence: commandline arg/API, envvar, user config, sys config). Default could be flowhub.io (for a particular user) For such public use, the protocol needs to be encrypted and authenticated.
When inside a project the runtime card (top-right) should show a list of currently available runtimes (of compatible type?). When in frontpage, a list of available runtimes should be available. Both should be fully dynamic, responding to availability.
Related: #64