This is a summary of the changes between RoboHydra 0.3 and RoboHydra 0.4. For full details, check the ChangeLog.
“Tests” (as in the collection of heads that get attached/detached at the same time) are now called “scenarios”. It’s a more appropriate name and much less ambiguous.
The use of tests in plugins is deprecated, and support for it will
be dropped the next version.
Now there’s an actual REST API to easily interact with the RoboHydra server: it allows you to check and manipulate the state of the heads and scenarios of a given hydra.
Scenarios can now be written in their own file in a special directory
inside the plugin, as opposed to being written inside the plugin’s
index.js. This makes it much easier to maintain plugins with many
scenarios. See the plugin documentation for details.
setHostHeader now true by defaultThis is a breaking change, but I don’t expect a lot of people to be bitten by this. On the other hand, I’m constantly bitten by the old counter-intuitive default value, and it’s hard to debug and figure out what the problem is if you don’t already know that RoboHydra doesn’t set it by default.
Plugins now receive a second module, fixtures, in the second
parameter to getBodyParts. This new module has a single function,
load, that allows you to load fixtures easily without having to
worry about paths. See the plugin documentation for
details.
Version 0.4 introduces a new feature, summoners, that allows you to use a single RoboHydra server for multiple users. Read the rationale, documentation and examples for more details.
RoboHydra has a new command-line option, -n, to avoid reading a
configuration file. It also has an option -P to specify a
comma-separated list of plugins to load on startup. These two options
combined allow you to start RoboHydra without any configuration file.
RoboHydra 0.4 also introduces a standard way to create your own head
classes, the roboHydraHeadType function.
registerDynamicHeadNow the function registerDynamicHead adds heads at the beginning
of the *dynamic* plugin, not the end. That way, heads added later
have precedence. Note that this implicitly changes the behaviour of
the admin web UI, too.
Another change is the addition of the concept of high-priority,
dynamic heads: see the documentation for details and the
standard logger plugin for an example of how to use it.
The new admin UI is a bit simpler and has been adapted to the changes in this version.
Back to the documentation index.