cbrake
April 19, 2022, 12:47pm
1
Did a little brainstorming about SIOT plugins/extending:
opened 12:42PM - 19 Apr 22 UTC
research
As simpleiot progresses, I'd like to start thinking along the lines of [platform… vs product](https://tmpdir.org/014/).
One key to successful platforms in support for packages/plugins. This issue is a placeholder to collect thoughts on this.
Both Elm and Go are compiled languages, and don't really support dynamic plugins very well. This improves security and stability, but reduces flexibility compared to languages like Python and Javascript. Some thoughts on this topic:
* https://github.com/hashicorp/go-plugin
* https://eli.thegreenplace.net/2021/plugins-in-go/
* https://caddyserver.com/docs/architecture
Using NATS as the plugin interface seems very natural. This works well for compiled in functionality or you can have separate programs written in different languages.
Extending the frontend seems a little harder -- perhaps the solution there is to have a declarative DSL that describes the frontend, and this could be easily extended and perhaps even described by nodes and points. Then any program could inject UI modifications. Since our data structures are limited to nodes/points, it seems it would be fairly simple to write a DSL that covers most of the basic dashboarding and data display features. This would even allow remote devices to control how the UI looks in the cloud. This seems like a very powerful idea. The ag industry has a standard called IOSBUS that is similar -- remote devices on a CAN bus can control to some extent what is on a remote display:
* https://agriculture.trimble.com/blog/what-is-isobus-how-to-use-isobus-on-my-farm/
* https://www.agleader.com/blog/what-is-isobus-2/
* https://en.wikipedia.org/wiki/ISO_11783
* https://github.com/moehman/PoolEditDist
This path let me to the thought that it would be very useful if remote (or local) devices/plugins could not only extend backend processing, but also control how a remote UI renders the view of a device/plugin.