Skip to content

Add support for symmetric behaviour of state machine #60

@VigneshVSV

Description

@VigneshVSV

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. Like external_call for actions and external_set for properties
  • rewrite external_call and external_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 to False 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    good first issueGood for newcomersintermediateintermediate level good first issues, might be little harder to complete

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions