Protocol

The ubii.framework makes heavy use of custom state machines to clearly separate behaviour and representation of objects that are closely related to ubii.proto messages.

For example a Ubi Interact Client is naturally represented by a Client message, but it’s behaviour should not be closely coupled to the representation – in the end, how a client connects to the master node, how it subscribes to topics, how it sends data, etc. is specific to the concrete implementation while the representation is shared – even across programming languages.

The abstraction of a state machine that defines behaviour of a entity in the ubii.framework is called a Protocol – don’t confuse it with the typing.Protocol for structural subtyping.

Note

Specific protocols implement the AbstractProtocol interface, and are usable in conjunction with a RunProtocol coroutine. The protocol object only defines the behaviour, the coroutine knows how to execute it

Specific Protocols are currently used for two things:

• define how a client node communicates with a master node during it’s lifetime, and how this communication results in a usable client API

• define a Processing Module’s behaviour during it’s lifetime

See also

ubii.framework.client.AbstractClientProtocol – base for client behaviour protocols

ubii.node.protocol – several client protocol implementations e.g. ubii.node.protocol.DefaultProtocol

ubii.framework.processing.ProcessingProtocol – protocol for processing modules