Hornwitser
bcd94709d2
Reverse the direction of the API for sending messages from
messageDefinition.send(link, { content });
to
link.send(new MessageClass(content));
and convert all message definitions to use the JSON serialisable class
pattern and explicit registration of message handlers, along with a
end-to-end based routing of messages instead of link to link.
The experience I gained from the existing way messages were defined and
sent over links was that it was difficult to understand for people
unfamiliar with the system. The automatic registration of message
handlers ment that code was being called as if by magic from nowhere
with no easy way to discover it. The manual forwarding and rules for
what can be sent where and how obscured its working.
The use of pure JSON as both input and output from message handlers made
it tedious to work with. Data had to be manually converted between the
program representation and the over the wire format, which made handler
code unplesant to write. Particularly because the over the wire format
used snake_case while the program code uses camelCase for variables.
The idea behind the decision to do it this way was to make it more clear
which data came from the wire and which from the program, and while this
worked it didn't make message handlers any nicer to write.
The direction of the API and magic registration of message handlers also
meant that a future migration to TypeScript would be troublesome. While
it may be possible to implement, the degree of TypeScript magic required
would go starkly against the principle of keep it simple stupid.
By refactoring to using the JSON serialisable class pattern most of
these issues go away. There is no longer a need to distinguish the on
wire format of messages with the program representation because the only
place that deals with the wire format of messages are the toJSON and
fromJSON methods on the classes themselves. Message handlers will work
with proper instances of classes instead of raw data, something that
makes them easier to write, and trivial to type with TypeScript.
End-to-end routing also simplifies sending messages that need to do
mulitple hops to reach the destination. And removes the need for having
all messages be specified in plugin's info module, as they can be routed
without having to be parsed completely.
The explicit registration of message handlers is something that I
thought would be tedious boilerplate code that could be automated away.
But experience now shows it to be the opposite. Allthough dull
repetition, the purpose it serves is to link together the code in a way
that humans can easily find. With explicit registration searching the
name of the message handler in the editor will show the registration that
ties it together with the type of message it handles and the kind of
registration. With implicit registration searching the name of the
message handler turns up only the handler with no clue as to what calls
it.
Clusterio Command Line Interface
Provides a command line interface for managing a Clusterio cluster.
Note that this document only describes the options and commands for managing clusterioctl itself, see Managing a cluster for the available commands used for managing a cluster.
Usage
npx clusterioctl <command>
Common options:
-
--plugin-list <file>JSON file to use for storing the list of plugins that are available to ctl. Defaults toplugin-list.jsonand will be created if it does not exist. See theplugincommand for managing this list. -
--config <file>JSON file to use for storing configuration for ctl. Defaults toconfig-control.jsonand will be created if it does not exist. See theconfigcommand for inspecting and modifying the configuration.
plugin <command>
Configure plugins available to be loaded by ctl. The available plugins will be automatically loaded and the commands they provide will be added to the ctl utility.
plugin add <path>
Add plugin either by require path or relative/absolute path to the plugin directory. A relative path must start with ./ or ../ (or .\ and ..\ on Windows) otherwise it will be assumed to be a require path for an installed package in node_modules.
For example, installing the Subspace Storage plugin:
npm install @clusterio/plugin-subspace_storage
npx clusterioctl plugin add @clusterio/plugin-subspace_storage
Since the plugin-list.json is shared between controller, host and ctl you usually only need to do this once per machine.
plugin remove <name>
Remove a plugin by its name. This should be done before uninstalling the plugin, otherwise there will be an error when Clusterio tries to load the info from the plugin. Removing and unistalling a plugin is usually not neccessary as the functions provided by the plugin can be disabled in the config.
For example, uninstalling the Subspace Storage plugin:
npx clusterioctl plugin remove subspace_storage
npm uninstall @clusterio/plugin-subspace_storage
Since the plugin-list.json is shared between controller, host and ctl you usually only need to do this once per machine.
plugin list
Lists the plugins set up to be available by name followed by path.
config-control
Manage the ctl configuration. This allows setting the url and token to the controller to manage.
config-control set <config-entry> [value]
Set a config entry to the given value. If value is not provided the entry is set to null. If the config entry is of type object the value must be a valid JSON serialization of an object.
See docs/configuration.md in the main repositiory for the available configuration.
config-control show <config-entry>
Shows the value for a single config entry.
config-control list
Lists up all configuration entries with their currently configured values.
See Also
Managing a cluster for the available commands used for managing a cluster.
The Clusterio repository for instructions on how to set up a cluster.