Mutable typed hierarchical environment variables
October 17, 2022•228 words
Hear me out: an architecture based on mutable hierarchical environment variables
Backed by ZeroMQ1 for messaging/IPC, SQLite for persistency (if needed), and JSON (grudgingly, since other options are even more horrible; OTOH we want to have type information, so something like protobuffers would be required) as payload.
Trivially easy subscription and property binding/propagation mechanism: stating that process X's x_out
variable is defined as process Y's y_out
and process Z's z_out
must be allowed to be defined (within X) as x_out = Y.y_out + Z.z_out
, or more generally x_out = some_fun(Y.y_out, Z.z_out)
, where some_fun()
is some Lua function (assuming we want to use Lua as expression language). If Y or Z now change their outputs (y_out
or z_out
), X's x_out
will automatically change. Throttling/debouncing must be possible.
Hotswapping of processes should not be ruled out.
Optionally define a framing that allows for something like Cap'n Proto's time travelling RPC.
This whole system would, of course, adhere to Virding's First Rule of Programming.
Throw in some tuple space ideas while we're at it2.
Edit(2023-01-16): BonasiDB (https://bonsaidb.io/about/), a local first DB with pub-sub, looks like it would fit the bill from a technological perspective.
-
Or nanomq? Maybe a better choice regarding integration of third party software, since it contains adapters between internal IPC and external MQTT, although the last time I tried this this did not quite work. ↩
-
https://software-carpentry.org/blog/2011/03/tuple-spaces-or-good-ideas-dont-always-win.html ↩