No, not that legendary creature - northis…
Although I admit that there’s something mythical about what I’m describing here.
I’m talking about the new design for JET.
My goal for oh so many years has been to create a development environment that scales across everything I want to develop software for. From the tiniest µC to the ever mightier web browser. With potentially a whiff of FPGA thrown in, as well as quite a range of Linux-based server functionality.
From JeeBus to HouseMon, using many different tools and techniques, I keep wanting to create a tool, preferably generic, practical, and understandable enough for others to use as well. Google for Tclkit and Starkits if you’re interested in precursors for this dream, and for the brave there are also my Metakit and Vlerq projects …
Sweet bygones … R.I.P.
Then one day I stumbled across Flow Based Programming and then:Pure Data (Pd):
Wow. No, not this mess, trying to cram a horrendously big control panel on-screen:
(from the Pure Data page on Wikipedia)
More something like this random example, a computer-based music synthesizer:
Pd was invented by Miller Puckette as a tool to create musical instruments in a visually programmable way. It’s meant to be used for live music performances.
Yet I see something completely different!
Pd is about visually composing data flows. It’s a visual call graph of nested functions. Each function (“object” in Pd terms, and “gadget” in the JET project) has a number of inputs and outputs, with messages flowing through them, across the wiring that’s currently in place.
Pd is similar to NodeRed andNoFlo, which both offer a graphical flow editor in the browser to construct and expand designs for managing message-based applications.
But at another level, Pd is much simpler: there’s no asynchronous behaviour in the core - the wiring is treated as immediate depth-first call/return tree. In fact, the non-audio side of Pd is surprisingly simple to implement. It’s a visual representation of an event-based single-threaded app.
This core level is what I’m after. I think it’s simple enough that it can be implemented on a low-end µC such as the JeeNode Zero.
And on the server. And in the browser.
Such a JET “engine” could be used in just about any context - just as “normal” code with nested function calls will fit on any µC.
This creates a loosely-coupled architecture, where there can be any number of basic building blocks (called “gadgets”), wired together visually in whatever way you like into compound structures called “circuits”.
The designer need no longer be one person.
Deep inside live the gadgets which can tie into hardware peripherals. On top of that, standard circuits can be constructed for various common tasks. These can be combined further as needed. And lastly, there’s the application level, where the whole configuration is designed and implemented, by wiring it all together.
Visually! – Back to the joy of drawing!
Or, if you prefer a more serious reason: because the designs are self-documenting.
Home monitoring, home automation, rule engines, graphical dashboards. Everything can be made up of gadgets and combined into circuits - from raw bits to entire apps.
Next week, it should become clear how this approach addresses a completely different problem area than Node-Red and NoFlo.
PS. JeeLabs sites are now served as HTTPS.