URI Schema » History » Version 9
« Previous -
Version 9/59
(diff) -
Next » -
Current version
J. Wienke, 02/21/2011 04:13 PM
URI Schema¶
rsb://composite1.composite2.composite3.componentNameXY/interfaceFooBar/portABC // EXPORT, creation of damain objects rsb://composite1/highLevelInterface/portABC // subscription URI
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