We consider how server-side plugins can assemble and maintain coordinated services under the guidance of transient client-side plugin configurations. See Alert Prototype
Our first thoughts were called Service Blocks. We're building these and learning as we go.
Our current prototype follows our good experience with starting and restarting Timer Logic.
A site is like a program. Editing the contents of a site is like revising the program.
A lineup is like an expression in a language. When we start/stop a plugin it is like saving/erasing a fragment of program written in the language.
A schedule.json asset file is like a compiled program that can be restarted with every server restart.
The node server is like the runtime environment that can load and execute a program. The app provides dynamic linking of program fragments via ServiceEmitters identified by slug/item strings.
An assembly of cooperating plugins will be dubbed a "service". The behavior of the service will depend on what configuration of client-side pages have been lined up when plugins are started.
Plugins that can cooperate server-side will announce this capability as "service-source" and bind through DOM discovery mechanisms client-side. A service-source consumer will convey the source's slug/item to its own server-side on start so that the server-sides can be linked.
Server-side plugins cooperate through emitting and handling events. An active server source will post its server-side EventEmitter to the app.eventEmitters registry. An active server source consumer will listen to the source's EventEmitter using event names to distinguish events it can handle.
See Implementing Service Logic
One cannot determine what configurations will be launched by examining the page json of a site. However, asset state will facilitate restarting a configuration and is therefor an accurate description of the running service. We should extend Graphviz's algorithmic diagrams to draw this dynamic state.
Events could carry a trace of slug/item/event that lead to any invocation. This way a plugin could look upstream to know what part of a computation it serves.
We're interested in how a site could be written as a pattern language for complex configurations. Pattern pages would describe some aspect of the configuration and include plugins that can be assembled and started to complete a choice (as in speech acts in natural language).
For a large system one might not view all relevant patterns or even all completed choices in a lineup together. But with well developed observation one could move around the complex system exploring alternative patterns and starting these as replacements (as in revising a narrative).
For a critical system the wiki and its server-side plugins might only model the behavior of a soon to be deployed system offering checks and performance estimates, possibly comparing these to live data from a production environment.
We'll collect similar applications we might configure if this proves both easy and reliable.
Smoker. Temperature sensor sends text when ready to cook or time to eat.
Spots. Digital radio monitors ham band recording stations heard and sends text when rare location is on the air.
Mildew. We anticipate remote sensing of conditions that require agricultural intervention. See Powdery Mildew
Push. In some data logging applications push to wiki would be preferable. Maybe extend Json plugin?
Backup. Regular, automated and off-site backups are classic 24x7 cron jobs that need wiki organization.
Blocks. Invented for kids, a handful of composable blocks could offer generic computation ready to start/stop. site