Description
Currently the state machine is accounted only for requests coming from remote clients. Before performing an operation, the current state of the state machine is checked and whether the property or action can be operated in that state is checked. All of this happens in the ZMQ event loop.
However, it may be useful to have symmetric behaviour of the state machine just like all the interaction affordances themselves which are symmetric. In other words, It does matter whether a property or an action is operated on server or the client, the behaviour and after affects are the same. Same should be the case for the state machine.
The purpose of this symmetric behaviour is that, it's possible to use the Thing
classes as basic device drivers, even if somebody is not interested in the networking part.
Steps:
- start with
main-next-release
branch where the "external" methods are implemented. Likeexternal_call
for actions andexternal_set
for properties - rewrite
external_call
andexternal_set
to place this logic somewhere else, so that they can be used both for server invokations and client requests. - add a flag in
global_config
, default toFalse
which toggles whether state machine must be symmetric or not. Default is non symmetric, because usually the server should have full control over invoking actions and properties and should not be obstructed by a state machine. - provide a python context statement
with disable_state_machine(thing_instance)
that disables the state machine for invocations under this statement.