Extension mechanism

[lawik]

The goal is to create a mechanism allowing us to re-use the existing connection and add new functionality based on messages received and passing messages back up the WebSocket.

The important part is that new features and functionality that are not core should be possible to deliver as libraries and plugged in via configuration. They should not be able to crash the Socket and prevent firmware updates from succeeding.

This is not complete isolation. Things could still be brought down by a really broken extension that brings down the :nerves_hub_link app but extensions run quite well separated.

This should let us update NervesHubLink without churning on sensitive code that could affect a lot of devices negatively.

[joshk]

Bringing in a couple of comments from Slack:

• We probably want a way to advertise to hub which extensions have been installed and their versions.
• We should also consider some lifecycle hooks, like “after join”, so extensions can send information after a successful connection.

[jjcarstens]

So there is a pattern I frequently use in firmware design which is basically pub/sub via Registry dispatching rather than require external extensions.

That allows one to create defined events/messages but not require external coupling to the runtime of NervesHubLink - I.e. Link does not have to care about what might be plugging into its events. It just republishes messages and subscribers consume then in whatever manner they want. In their own supervision and runtime.

With this extension/plugin method, we're still mixing unknown external concerns into the Link runtime and supervision. It becomes susceptible to the frailty of dependency in sort of a cyclic way

[lawik]

Replace by #220