One of restrictions with Viinex 2.0 was that it did not allow its client software to change a configuration of Viinex instance while the latter is running. If there was a need to add a camera or modify some aspect of one of Viinex objects’ behavior — then one had to stop the whole instance of Viinex 2.0, change its configuration, and start the instance over. Essentially, it means that an instance of Viinex cannot observe a change of its own configuration.
As of Viinex 2.0 build 218, however, this is no longer the case. Viinex 2.0 now has the means for creating and dropping of the groups of objects right in the run time. So if one needs to dynamically create or remove, for example, a video source, — this is now possible with Viinex 2.0. And just like with all other functionality, — we provide the HTTP API for that: the software that uses Viinex can add or remove groups of objects programmatically.
There is, however, still an issue to talk over. A reason why we made the initial decision on the immutable configuration and why used to stick to it, is the following. When a change to the configuration of a system is performed, and the system consists of several objects acting together and depending on each other, — in order to keep the configuration sane, the changes to multiple objects’ configuration should be done atomically, at once. For example, if one wants to add a camera to the system, acquire events from that camera, set up a rule to react to certain detector events, and write the stream from that camera into the video archive, — if all these changes are done to the configuration of the system in the run time, one change after another, — then the system configuration is pretty much inconsistent, until the very last change is done.
We think this is a bad pattern, and we still force the software that uses Viinex to change the configuration “atomically”, so that all changes related to several objects that are intended to work together, are applied at once. This has a strong advantage in the form of that the objects that rely on each other to function properly — can safely assume that their dependencies in the same instance of Viinex won’t disappear because of configuration change. The sanity of configuration can be checked when a Viinex instance is started, and that sanity is guaranteed for the whole run time.
The way we added the feature of dynamic creation and removal of Viinex objects tries to take into account these considerations. Particularly, — the objects which are added to or removed from Viinex, are added not one by one, but as a group of objects, together with the links established between newly added objects. Such groups are called clusters in Viinex 2.0. It is important that, while the clusters can be added and removed, — configuration of each cluster is still immutable (from the point of view of respective cluster). In order to change the configuration of a cluster, — it should be deleted and then created again, with a new configuration.
One more consequence of this clusters’ configuration immutability principle is that objects within a cluster can only be linked to each other, but not to objects in other clusters. This is because links are the part of configuration, which is immutable for every separate cluster.
One can overcome this restriction by, for instance, establishing a network connections between objects in different clusters. A network connection is fragile by assumption, and objects’ implementations in Viinex are prepared to handle such connections failure, — which would occur in case if one of the clusters that connected objects belong to is removed. This would be OK for the other end of the connection, because the network connection is expected to fail, — unlike the link between Viinex objects in a cluster or in the main configuration.
We believe that this approach is more honest and straightforward
and this simplicity pays back to those who uses Viinex 2.0, compared to the attempts to handle the inconsistent state of a system during the gradual configuration change.