Command

When a Command has finished initializing, it calls “publish_service” to publish its service type (if it has a service type which might not be the case for a command line for example). This announcement makes the given command available for connections from remote objects.

Messages received by the command are forwarded to the Root.

A Command serves as a some kind of tunnel for a given protocol. You can only register one Command for a given protocol on a Root object.

For example, you might have an OscCommand responsible for the “osc” protocol, an HTTPCommand for “http” and a PipeCommand for “whatever”. With these commands in place, any object in the tree can refer to remote objects via specific commands by sending message with the matching protocols. It is Root’s responsibility to pass the messages to the right Command.

When a remote object connects to a Command, it is automatically registered in the list of “observers” (until the registration’s time-to-live expires). All return values produced by calls to the Root are sent to every observer of every Command.

When a command receives a “reply” messages, it first tries to see if it has a root proxy registered for the same remote origin. If this is the case, it routes the reply message to the root proxy by calling handle_reply..

[remote] reply ---> Command ---> RootProxy.handle_reply