URI Schema¶

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

Just Brainstorming¶

scheme://domain:port/path?query_string#fragment_id

rsb://composite1.composite2:<PortId>/service/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:   rsb+spread://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

Targets¶

• Service vs. Interface
• Composite
• Port

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?

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

Open Issues¶

• Action encoding

Further Proposals we discussed¶

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