Robotics Service Bus

h1. URI Schema

<pre>
rsb://composite1.composite2.composite3.componentNameXY/interfaceFooBar/portABC // EXPORT, creation of damain objects
rsb://composite1/highLevelInterface/portABC // subscription URI
</pre>

h2. Just Brainstorming

<pre>
scheme://domain:port/path?query_string#fragment_id

rsb://composite1.composite2:<PortId>/service/interface/port?param_n=n#filter:cond

rsb://machine.domain.tld:<PortInstanceId>/composite1/composite2/interface/port?param_n=n#filter:cond

More complex example (Q: How to deal with input and output ports?)

rsb://composite1.composite2:<PortId>/interface/port?param_n=n#filter:cond

Informer: rsb://biron.hal.camera/image/left/o/left/?param1=12

Listener A:
Listener: rsb+spread://biron.hal.camera/image/left/i rsb://biron.hal.camera/image/left/i
Listener B: rsb+shamem://biron.hal.camera/image/left/i

Subscription-URI: rsb://biron.hal.vision/grab/out/left/#xpath:/frame
</pre>

h2. Targets

* Service vs. Interface
* Composite
* Port

h2. Use Cases

* Introspection URIs? HTTP possible?
* Subscription on each node of the tree (aggregation vs. filtering)
* Model vs. System URI? Should not exist?
* Every active object must be identifiable
* Data part of URI? Probably not?
* RESTful API?

h2. Identified Problems

* Data space (motion/wheel/left) is orthogonal to current model structure
** Using this concept could generate unmodelled ports in reverse engineering
** Is this required if we model our system?
** Wildcards in URLs?
** Idea: Second model tree for AggregationInterfaces that combine Ports from different Components / Composites etc. and automatically derive their base data type
*** Different Protocol part in the URI for these interfaces to subscribe on
*** We do not need data hierarchies (only required for function overloading), instead only collections of interfaces are required and an intersection operation to derive the resulting type of an aggregation

h2. Open Issues

* Action encoding