Robotics Service Bus: Issueshttps://code.cor-lab.de/https://code.cor-lab.de/favicon.ico?14019720732015-08-26T14:47:20ZOpen Source Collaboration Platform
Redmine Enhancement #2368 (New): Add average rate field to logger styleshttps://code.cor-lab.de/issues/23682015-08-26T14:47:20ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>number of events / number of origins</p>
<p>+ variance?</p> Enhancement #2066 (Feedback): added WireSchemaFilter + FilterCombinationhttps://code.cor-lab.de/issues/20662014-10-24T10:04:07ZR. Haschkerhaschke@techfak.uni-bielefeld.de
<p>WireSchemaFilter acts as a type filter, but could be applied before conversion<br />FilterCombination allows to combine several filters in AND (match all) or OR (match any) fashion</p> Feature #1870 (New): Allow (optional) parallel method callshttps://code.cor-lab.de/issues/18702014-05-08T12:36:06ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<ul>
<li>Johannes will commit patches containing a short-term workaround for C++ and Java</li>
</ul> Enhancement #1777 (In Progress): Add commandline options to exclude scopes from logging https://code.cor-lab.de/issues/17772014-02-18T16:18:29ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>Allow to exclude certain scopes from the logging process using command line arguments.</p> Feature #1771 (In Progress): Add META block to TIDELog backendhttps://code.cor-lab.de/issues/17712014-02-14T11:48:57ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.deFeature #1770 (In Progress): Add TYPE block to TIDELog backendhttps://code.cor-lab.de/issues/17702014-02-14T11:43:09ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.deEnhancement #1757 (In Progress): Add intermediate results to request-reply patternhttps://code.cor-lab.de/issues/17572014-02-10T10:28:55ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>Allow RPC methods to provide intermediate results during processing using asynchronous communication.</p> Enhancement #1550 (New): "Auto" mode of the socket transport should be smarterhttps://code.cor-lab.de/issues/15502013-06-25T12:02:55ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>When configured as <code>server = auto, host = NOT-THE-LOCAL-HOST</code>, the process should not attempt to act as server.</p>
<p>Note however, that this may be harder to implement than it sounds.</p> Enhancement #1515 (New): Add data type to all participants, especially listenershttps://code.cor-lab.de/issues/15152013-05-27T16:29:49ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>This would automatically allows to select the correct converter for deserialization. Also, right now the situation is quite seldom that handlers with different data types can work correctly on a single listeners.</p>
<p>We should still allow the Any Type for dynamic languages and situations.</p> Tasks #1422 (Feedback): Add a plugin which registers the XOP converterhttps://code.cor-lab.de/issues/14222013-02-18T20:56:04ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.deTasks #1227 (Feedback): Add a CMake macro for RSB pluginshttps://code.cor-lab.de/issues/12272012-11-05T17:47:35ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>The <code>CMakeLists.txt</code> files of the currently existing plugins are very similar.</p>
<p>I suspect we could provide a CMake macro which performs 90 % of the work for most plugin projects.</p>
<p>If we decide to do this, it should be mentioned in the manual.</p> Feature #1149 (Feedback): Allow checking if handlers are registered in Listenerhttps://code.cor-lab.de/issues/11492012-08-24T15:00:38ZM. Meiermmeier@techfak.uni-bielefeld.de
<p>For our migration to rsb we need some sort of functionality provided by the <code>rsb::Listener</code> which allows us to check if there are any handlers registered. In earlier version we used the <code>std::set<HandlerPtr></code> in <code>rsb::Listener::Impl</code> which has been removed recently (<a href="https://code.cor-lab.de/projects/rsb/repository/rsb-cpp/revisions/de636d5533afee40af3b2a2ecee4db6c8325597c" class="changeset" title="Removed unused member variable in src/rsb/Listener.cpp * src/rsb/Listener.cpp: removed unused mem...">rsb-cpp|de636d55</a>). So we would like to have at least some kind of <code>bool hasHandlers()</code> available.</p> Enhancement #1054 (New): "auto" server mode is inefficienthttps://code.cor-lab.de/issues/10542012-07-02T14:26:09ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>Currently the "auto" server mode is implemented as follows:</p>
<ol>
<li>Maybe act as server
<ol>
<li>If there is a bus server object for the endpoint, use it</li>
<li>If not, try to open a listen socket (for the configured endpoint) *</li>
</ol>
</li>
<li>Maybe act as client
<ol>
<li>If there is a bus client object the end point, use it</li>
<li>if not, try to connect to a listen socket (for the configured endpoint) *</li>
</ol></li>
</ol>
<p>The operations marked with "*" are potentially expensive (due to nameserver queries etc.).</p>
<p>When a process acts as client, steps 1.1, <strong>1.2</strong> and 2.1 are repeated for each created participant.</p> Enhancement #1023 (In Progress): Add Transport class [C++]https://code.cor-lab.de/issues/10232012-06-25T12:48:16ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
The new <code>Transport</code> class would represent properties of transport as a whole (e.g. Spread, socket, inprocess),
<ul>
<li>Instances should aggregate the respective factory objects (in-push, in-pull, out, etc.)</li>
<li>Some Connector properties such as schema list could be moved into the new <code>Transport</code> class</li>
</ul> 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>