Robotics Service Bus: Issueshttps://code.cor-lab.de/https://code.cor-lab.de/favicon.ico?14019720732011-08-19T21:29:32ZOpen Source Collaboration Platform
Redmine Bug #515 (New): Data handlers cannot deal with unexpected typeshttps://code.cor-lab.de/issues/5152011-08-19T21:29:32ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>See also: the first topic of <a href="https://code.cor-lab.de/projects/rsb/wiki/Meetings2011-08-02" class="wiki-page">Meetings2011-08-02</a>.</p>
<a name="Problem-Statement"></a>
<h2 >Problem Statement<a href="#Problem-Statement" class="wiki-anchor">¶</a></h2>
<p>Associated handlers of listeners basically have to expect events with payloads of any type (unless a type filter is installed on the listener). This can be a problem for handler classes like <code>DataHandler</code> or <code>DataFunctionHandler</code> in C++ that can only handle events with certain payload type, because the behavior for events with incompatible payload types has not been specified yet.</p>
Problems of the current implementation (restricted to C++ for clarity here):
<ul>
<li>Clients may get the impression that handlers like <code>DataHandler</code> cause the associated listener to only receive events that have compatible payload types</li>
<li>This is currently not true; Instead, the program will most likely crashes due to an invalid <code>static_pointer_cast</code></li>
</ul>
<a name="Potential-Solutions"></a>
<h2 >Potential Solutions<a href="#Potential-Solutions" class="wiki-anchor">¶</a></h2>
<a name="Signal-Errors-for-Incompatible-Events"></a>
<h3 >Signal Errors for Incompatible Events<a href="#Signal-Errors-for-Incompatible-Events" class="wiki-anchor">¶</a></h3>
<p>Classes like <code>DataHandler</code> could signal an error when encountering incompatible payload types.</p>
Variations include
<ul>
<li>Aborting the program</li>
<li>Displaying an error message but continuing</li>
<li>Configurable behavior</li>
</ul>
<a name="Drop-Incompatible-Events"></a>
<h3 >Drop Incompatible Events<a href="#Drop-Incompatible-Events" class="wiki-anchor">¶</a></h3>
<p><code>DataHandler</code> and friends could check the payload types of events being dispatched to them and simply ignore events with incompatible payload types.</p>
<p>This would lead to inefficient processing if a single listener with multiple handlers for different payload types was used, since the dispatching mechanism would still dispatch all events to all handlers which would then drop unsuitable events only after most of the processing already happened.</p>
<a name="General-Considerations"></a>
<h3 >General Considerations<a href="#General-Considerations" class="wiki-anchor">¶</a></h3>
Both previously mentioned solutions can be implemented in several different ways:
<ul>
<li>Introduce a common base class for <code>DataHandler</code> and friends that implements the chosen behavior (error or drop) in a <code>processable</code> method:
<ul>
<li><code>processable</code> would be called to determine whether an event should be dispatched to a handler</li>
<li>If <code>processable</code> returned <code>true</code>, the event would be dispatched in the usual way by calling <code>handle</code></li>
</ul>
</li>
<li>Integrate feedback from handlers into the dispatch logic
<ul>
<li>Dispatching could display warnings or signal errors if events are dropped because they are not handled by any handler</li>
<li>This could be achieved by adding a return value to <code>handle</code> or the above mentioned <code>processable</code> method
<ul>
<li>The downside of a return value for <code>handle</code> would be potential confusion of clients implementing the <code>Handler</code> interface</li>
</ul>
</li>
</ul>
</li>
<li>It may be necessary for efficiency reasons to communicate information regarding the desired payload types of registered handlers all the way back to the transport layer</li>
</ul> Support #483 (New): Document Connector Extension Pointhttps://code.cor-lab.de/issues/4832011-08-07T19:09:07ZS. Wredeswrede@cor-lab.uni-bielefeld.de
<p>How to write a new connector, e.g., an XMPP connector in C++?</p> Enhancement #475 (New): Use RST IDL Type for Protocol Buffer Tutorialshttps://code.cor-lab.de/issues/4752011-08-05T16:00:13ZS. Wredeswrede@cor-lab.uni-bielefeld.de
<p>Currently, a separate IDL is checked in and used for the protobuf tutorials. Why not just use a standard RST type?</p>
<p>Provide conditional compilation of this example to depend optionally on RST.</p> Feature #471 (New): Support for RPC clients which do not require a running server parthttps://code.cor-lab.de/issues/4712011-08-04T15:17:20ZL. Schillingmannlschilli@techfak.uni-bielefeld.de
<p>It should be simple to code a rpc client which is able to handle different states of the rpc server availability:</p>
<ul>
<li>reconnect if server disappears and reappears</li>
<li>detect server availability</li>
<li>wait for server to appear (with timeout)</li>
</ul> Bug #390 (New): Handling of sendTime in Informerhttps://code.cor-lab.de/issues/3902011-06-23T19:27:18ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>An <code>Informer</code> returns an <code>Event</code> to the caller after sending it. This is especially useful if the event is created in the informer on behalf of the calling client. Currently, returned events have their <code>sendTime</code> timestamp set in some way. However, it is not quite clear, how this timestamp should be set. There are (at least) the following possibilities:</p>
<ul>
<li>The informer sets the timestamp before passing the event to connectors for sending</li>
<li>Each connector somehow locks the event and sets the timestamp. The least recent connector "wins" </li>
<li>The connector sets the timestamp only if there is just one connector</li>
<li>The informer sets the timestamp after the event has been processed by all connectors</li>
</ul>
<p>After this has been decided, update</p>
<ul>
<li>UML sequence diagrams</li>
<li><a href="https://code.cor-lab.de/projects/rsb/wiki/EventProcessing" class="wiki-page">EventProcessing</a></li>
<li>Implementations</li>
</ul> Feature #381 (New): Timestamp compatibilty to ROS and YARPhttps://code.cor-lab.de/issues/3812011-06-21T13:47:53ZAnonymous
<p>Right now, default unit of RSB timestamps seems to be microseconds. If they would be given in seconds (same precision of course), timestamp format would be compatible with both ros::Time and yarp::os::Time (both in seconds with six positions after decimal point).<br />Just as an idea to get a similar interface and therefore easier migration in both directions.</p> Enhancement #380 (New): Support URIs for Participant Configurationhttps://code.cor-lab.de/issues/3802011-06-20T22:24:27ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>According to "Transport-specific URLs" in <a href="https://code.cor-lab.de/projects/rsb/wiki/URI_Schema" class="wiki-page">URI_Schema</a></p> Enhancement #379 (New): Support URIs for Participant Configurationhttps://code.cor-lab.de/issues/3792011-06-20T22:24:15ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>According to "Transport-specific URLs" in <a href="https://code.cor-lab.de/projects/rsb/wiki/URI_Schema" class="wiki-page">URI_Schema</a></p> 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.deEnhancement #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 #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> 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>