Robotics Service Bus: Issueshttps://code.cor-lab.de/https://code.cor-lab.de/favicon.ico?14019720732011-06-20T21:24:06ZOpen Source Collaboration Platform
Redmine Tasks #377 (New): Pull-style Event Receivinghttps://code.cor-lab.de/issues/3772011-06-20T21:24:06ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.deTasks #376 (New): Pull-style Event Receivinghttps://code.cor-lab.de/issues/3762011-06-20T21:23:58ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.deTasks #373 (In Progress): Move Spread Transport into separate Systemhttps://code.cor-lab.de/issues/3732011-06-19T18:07:18ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<ul>
<li>Probably <code>rsb-spread</code></li>
<li>To what extend should the Protocol Buffer code be included in the move?</li>
</ul> Enhancement #351 (New): Revise Converter Selection Mechanismhttps://code.cor-lab.de/issues/3512011-06-09T10:33:38ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>The converter selection mechanism has partially been extended to support more powerful selection strategies (see <a href="https://code.cor-lab.de/issues/304" class="issue tracker-4 status-3 priority-4 priority-default closed" title="Wildcard Mechnism for Converter Selection (Resolved)">#304</a>).</p>
However, the following aspects have not been adopted to this extension, yet:
<ul>
<li>The Java implementation does not have an implementation of any converter selection mechanism</li>
<li>Configuration
<ul>
<li><code>ParticipantConfig.Transport</code> is not suitable for extended selection strategies</li>
<li>Syntax and semantics for configuring new converter selection strategies has not yet been specified</li>
<li>Obviously, this specification has not yet been implemented</li>
</ul></li>
</ul> Bug #344 (New): C++ Spread: Transport-level errors are not handled properlyhttps://code.cor-lab.de/issues/3442011-06-05T15:37:24ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
The ReceiverTask class has (at least) two potential causes of errors
<ul>
<li>Spread errors (currently ignored)</li>
<li>Converter errors (currently not handled, ignored at call site)</li>
</ul> Feature #340 (Feedback): Implement Distributed Namingservicehttps://code.cor-lab.de/issues/3402011-05-30T09:51:10ZS. Wredeswrede@cor-lab.uni-bielefeld.de
<p>For introspection in an RSB system comprised by multiple transports, a nameservice implementation is needed.</p>
<p>In contrast to ROS, YARP, XCF, a distributed nameservice is required.</p>
<p>Implementation could be based on:</p>
<ul>
<li>UPNP (btw: could enable DLNA-based use cases...)</li>
<li>Multicast-DNS (check compatibity)</li>
<li>ROS Master (at least evaluate it?)</li>
</ul>
<p>Check relation to model-layer.</p> Tasks #331 (In Progress): Generate and export API Documentationhttps://code.cor-lab.de/issues/3312011-05-26T20:40:44ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.deEnhancement #322 (In Progress): Introspectable Configuration Options [Java]https://code.cor-lab.de/issues/3222011-05-25T18:11:35ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
It should be possible to query the supported configuration options of connectors:
<ul>
<li>This should work without instantiating the connectors, if possible</li>
<li>The obtained information should be sufficiently detailed to generate
<ul>
<li>Configuration file schemas</li>
<li>Commandline option descriptions (when these get implemented)</li>
<li>Help texts</li>
</ul></li>
</ul>
Introspection should yield:
<ul>
<li>Name ✓</li>
<li>Supported (URI-)schemes ✓</li>
<li>Wire-type</li>
<li>"Remoteness", see <a href="https://code.cor-lab.de/issues/1028" class="issue tracker-4 status-3 priority-4 priority-default closed" title="Expose connector "remoteness" in transport package [Java] (Resolved)">#1028</a> ✓</li>
<li>Configuration options ✓</li>
</ul> Enhancement #320 (In Progress): Introspectable Configuration Options [Python]https://code.cor-lab.de/issues/3202011-05-25T18:09:36ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>For Python, we can probably store the introspection information in the connector class objects.</p>
It should be possible to query the supported configuration options of connectors:
<ul>
<li>This should work without instantiating the connectors, if possible</li>
<li>The obtained information should be sufficiently detailed to generate
<ul>
<li>Configuration file schemas</li>
<li>Commandline option descriptions (when these get implemented)</li>
<li>Help texts</li>
</ul></li>
</ul>
Introspection should yield:
<ul>
<li>Name ✓</li>
<li>Supported (URI-)schemes</li>
<li>Wire-type</li>
<li>"Remoteness", see <a href="https://code.cor-lab.de/issues/1029" class="issue tracker-4 status-3 priority-4 priority-default closed" title="Expose connector "remoteness" in transport package [Python] (Resolved)">#1029</a> ✓</li>
<li>Configuration options</li>
</ul> Feature #318 (New): Support QoS in Spread connectorhttps://code.cor-lab.de/issues/3182011-05-24T20:26:30ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<ul>
<li>Spread flags for outgoing messages
<ul>
<li>Reliability</li>
<li>Ordering</li>
</ul>
</li>
<li>Conditional pruning of assembly pools</li>
</ul> Enhancement #286 (In Progress): Introspectable Configuration Options [C++]https://code.cor-lab.de/issues/2862011-05-12T12:34:00ZJ. Wienkejwienke@techfak.uni-bielefeld.de
It should be possible to introspect connectors (precisely connector implementations):
<ul>
<li>This should work without instantiating the connectors, if possible</li>
<li>The obtained information should be sufficiently detailed to generate
<ul>
<li>Configuration file schemas</li>
<li>Commandline option descriptions (when these get implemented)</li>
<li>Help texts</li>
</ul></li>
</ul>
Introspection should yield:
<ul>
<li>Name ✓</li>
<li>Supported (URI-)schemes ✓</li>
<li>Wire-type</li>
<li>"Remoteness", see <a href="https://code.cor-lab.de/issues/1027" class="issue tracker-4 status-3 priority-4 priority-default closed" title="Expose connector "remoteness" in transport package [C++] (Resolved)">#1027</a> ✓</li>
<li>Configuration options ✓</li>
</ul> Enhancement #284 (In Progress): Specify barricade strategy for passed argumentshttps://code.cor-lab.de/issues/2842011-05-11T15:32:25ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>When do we want to use exception handling, when assertions? We should define at which level passed arguments are expected to be valid and where exceptions are expected.</p> Enhancement #283 (In Progress): Unify exception handlinghttps://code.cor-lab.de/issues/2832011-05-11T15:29:05ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>Currently there is a mixture of using a common RSB Exception base class and using std exceptions if possible. We should decide on one strategy and refactor the existing code base.</p> Bug #52 (New): State model/checking for modifications on InRouteConfigurators requiredhttps://code.cor-lab.de/issues/522010-08-19T12:03:33ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>Right now subscriptions on the router are passed to the port even if both are not activated. For the spread port this e.g. results on a call on the uninitialized connection right now and would need complex caching.</p> Feature #45 (New): Add Conditional Parsing for User Data in Receiver Processhttps://code.cor-lab.de/issues/452010-08-18T19:00:40ZS. Wredeswrede@cor-lab.uni-bielefeld.de
<p>Currently, the ReceiverTask parses incoming notfications including the contained user data payload. Probably, content can be parsed on demand later if a subscription matches or a filter explicitely requires it.</p>