Robotics Service Bus: Issueshttps://code.cor-lab.de/https://code.cor-lab.de/favicon.ico?14019720732015-04-21T14:24:14ZOpen Source Collaboration Platform
Redmine Feature #2227 (Feedback): Symlinks/Aliases for Scopeshttps://code.cor-lab.de/issues/22272015-04-21T14:24:14ZC. Leichsenringcmertes@cit-ec.uni-bielefeld.de
<p>For various reasons it would be useful to make the same informer have multiple scopes, i.e. de facto symlinks or aliases for scopes. Example use cases would be:</p>
<ul>
<li>provide a list of services or devices by human-readable name and number</li>
<li>list services by different criteria</li>
<li>provide different formats under different scopes but link to a default scope</li>
<li>.... basically every reason why one would want symlinks in file systems, too</li>
</ul> Enhancement #2149 (Feedback): Provide simple API to programmatically set preferred convertershttps://code.cor-lab.de/issues/21492015-01-04T06:57:44ZR. Haschkerhaschke@techfak.uni-bielefeld.de
<p>Currently converters can only be configured via the RSC config system. <br />Preferred converters are filtered out in rsb::ParticipantConfig::Transport::handleOption.</p>
<p>As usually the programm needs to specifiy its required converters (rather than the system), there should be an easy mechanism to specify preferred converters on that level.<br />I suggest to add methods addConverter(wireschema, datatype) and addConverters(ConverterNames)</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> Enhancement #2041 (Feedback): merge URI spec into ParticipantConfighttps://code.cor-lab.de/issues/20412014-10-06T21:17:18ZR. Haschkerhaschke@techfak.uni-bielefeld.de
<p>provide utilities to parse rsb-URIs (see <a class="external" href="http://docs.cor-lab.de//rsb-manual/trunk/html/specification-uris.html">http://docs.cor-lab.de//rsb-manual/trunk/html/specification-uris.html</a>)</p>
<p>provide thin uri class, full-fledged class might become part of boost: <a class="external" href="https://github.com/cpp-netlib/uri">https://github.com/cpp-netlib/uri</a></p>
<p>provide ParticipantConfig ParticipantConfig::merge (const uri&) to merges uri-parameters of existing ParticipantConfig<br />- uri parameters, if available, overwrite existing parameters<br />- new transport is added if neccessary</p>
<p>provide ParticipantConfig ParticipantConfig::replace (const uri&): as merge, but disable (or remove?) other transports</p>
<p>raises std::invalid_argument on failures:<br />- invalid URI syntax<br />- host/port given, but no transport specified</p> Bug #1849 (Feedback): Call tool does not complain if it can't decode a replyhttps://code.cor-lab.de/issues/18492014-04-17T13:01:39ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>The call tool simply blocks if it receives a reply for a method with a data type that cannot be deserialized. No message is given to the user.</p> Enhancement #1831 (Feedback): Provide introspection functionality as shared object (as opposed to...https://code.cor-lab.de/issues/18312014-04-01T14:40:48ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
Questions to consider:
<ul>
<li>How should the shared object be exported on the CMake-level?
<ul>
<li>Probably similar to converter plugins in <a href="https://code.cor-lab.de/projects/rst" class="project">Robotics Systems Types</a></li>
<li>However, we probably do not want CMake components since they make everything more complicated</li>
<li>Probably add a <code>RSB_INTROSPECTION_LIBS</code> variable and export it in <code>rsb-config.cmake</code></li>
</ul>
</li>
<li>How should the initialization and cleanup be performed when the introspection shared object is used?</li>
<li>What happens if a client programs links against the introspection shared object and then loads the plugin?</li>
</ul> Feature #1767 (Feedback): Export default plugin folderhttps://code.cor-lab.de/issues/17672014-02-13T16:38:09ZAnonymous
<p>There is some kind of <em>default plugin folder</em> (currently <code>lib/rsbx.x/plugins</code>), where several downstream projects install their plugins (e.g. rst converters, rsb-spread, ...) for convenience. Up to now the downstream projects construct this path by hand.</p>
<p>I suggest that we export e.g. a <code>RSB_DEFAULT_PLUGIN_PATH</code> via cmake config for downstream projects to use. Does that make sense?</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> Bug #688 (Feedback): Name resolution does not work with absolute package nameshttps://code.cor-lab.de/issues/6882011-10-31T14:54:49ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>for the logger, a proto file with rsb.protocol.Notification as a member type declaration cannot be resolved. Starting with a dot, this works.</p> Enhancement #551 (Feedback): Language-specific configurationhttps://code.cor-lab.de/issues/5512011-09-07T08:09:08ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>We already have things like<br /><pre>
[transport.spread.converter.cpp]
bool = bool
image = IplImage
</pre><br />in the current configuration scheme.</p>
<p>With the introduction of more technical tunable parameters (e.g. <a href="https://code.cor-lab.de/issues/548" class="issue tracker-5 status-3 priority-4 priority-default closed parent" title="Threadless RSB (Resolved)">#548</a>, <a href="https://code.cor-lab.de/issues/550" class="issue tracker-2 status-3 priority-4 priority-default closed child" title="Selection of Receiving Strategy (Resolved)">#550</a>, <a href="https://code.cor-lab.de/issues/551" class="issue tracker-5 status-4 priority-5 priority-high3" title="Language-specific configuration (Feedback)">#551</a>), it seems unlikely that a single configuration file can be used to configure all language implementation simultaneously.</p>
Two solutions come to mind:
<ul>
<li>In addition to <code>rsb.conf</code>, have language-specific configuration file like <code>rsb-cpp.conf</code> that take precedence over the generic one</li>
<li>Extend the approach mentioned above and introduce language-specific options like <code>eventprocessing.receivingstrategy.cpp</code></li>
</ul> Enhancement #477 (Feedback): Test / Reconsider Distributed Logginghttps://code.cor-lab.de/issues/4772011-08-05T16:37:34ZS. Wredeswrede@cor-lab.uni-bielefeld.de
<ul>
<li>Is this part of RSB functionality?</li>
<li>Part of an additional library?</li>
<li>Which logging frameworks to support?</li>
<li>What is the common format (so far it was log4j's XML format)</li>
</ul> Tasks #432 (Feedback): Logo Designhttps://code.cor-lab.de/issues/4322011-07-20T14:40:17ZS. Wredeswrede@cor-lab.uni-bielefeld.de
<p>Florian made me think about this one...</p>
<p>He chose <a href="http://www.rsb4.de/images/stories/Standardbilder/rsb-Fahne.jpg" class="external">this picture</a> as an icon for RSB in the toolkit...</p>
<p>If we stick to the name RSB, I could imagine a number of Bender-like robot marching with RSB flags... But probably that would be too militaristic theme as Bender surely is a bad guy...</p>
<p>We need a meeting on this. ;-)</p> 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>