The JET project is a collection of ideas and some experimental code to try and realise that elusiveUnicorn from my last post.
A picture explains best what JET is about:
There are three sub-systems involved:
The web browser acts as a front end and user interface for everything. You launch it when you need to see, adjust, or extend the current setup.
The server is the always-on part of the system, powered up 24 / 7. A lean-and-mean low-end Linux board such as a Raspberry Pi would be a fine choice.
The nodes are the µC-based eyes and ears of the system, with lots of sensors to read physical conditions as well as actuators to control the outside world. Most of those nodes could be battery-powered and wireless JeeNodes.
Many different technologies join forces in JET, due to the range of hardware involved and the numerous different requirements for each. Unlike most web-based apps, the main compute power will be in the browser (i.e. laptop or mobile) - i.e. not the server!
Folie will connect the server to the outside world, usually through a (USB-based) serial port, but other scenarios are possible. The most central component is the Mosquitto MQTT message broker, which also doubles as a (secure) HTTP + Web Socket server.
There can be multiple instances of Folie. Other software can be accommodated by having it connect to MQTT via sockets.
But the unifying concept here is really the “circuit-of-gadgets” flow mechanism, using a little engine running in all the different parts of this system. These Pd-like circuits drive all the main logic and orchestrate all the required pieces. Using a visual designer in the browser, everything can be set up, customised, and adjusted - at any time.
So much for my long-term view of JET. Clearly, most of this doesn’t exist yet…
Today’s reality is very different. I need to start with a workable development setup, and this is what it looks like right now:
There is a clear distinction between the production side of JET, which is to become the permanent and easily-distributable “deliverable” and thedevelopment side at the bottom, which is only needed to tinker under the hood.
For a very long time to come, I expect this tinkering to be the only visible activity of it all: JET is not going to be built in one day!
The good news is that I’ve finally settled on the technologies to use, and that all of these pieces are starting to work and fit together. I have a first flow engine prototype working in Go (which is calledJET/Glow), as well as a similar one in CLJS (part ofJET/Web).
To ensure that the above story will unfold as intended, I’m now working on a design for the flow engine in C and in Forth. These will be more challenging, since they both require explicit memory management of all the messages flying around. I’ll be using the C design to flesh out all the details, before porting it to Forth. Needless to say, these low-end µC versions will need to work in a severely resource-constrained context.
Update - the basic flow engines in C and in Forth are starting to work. They sidestep mem-mgmt issues for now by only sending around ints as messages -it’s a start …