Re: [ros-users] Making message transport more modular?

Forside
Vedhæftede filer:
Indlæg som e-mail
+ (text/plain)
Slet denne besked
Besvar denne besked
Skribent: User discussions
Dato:  
Til: ros-users@code.ros.org
Emne: Re: [ros-users] Making message transport more modular?
I'd definitely support this; I've been wanting to experiment with SCTP
(http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol) as a
transport layer, but had no idea how to get it working with ROS. Having
some well-supported interface in ROS to tie in new transports would make
that MUCH easier!

Thanks,
Cem Karan

>------------------------------
>
>Message: 9
>Date: Wed, 23 May 2012 09:53:21 +0200
>From: Cedric Pradalier <>
>To: User discussions <>
>Subject: [ros-users] Making message transport more modular?
>Message-ID:
>    <CAOQFJrLoKa08hyLgXv1O+MO3=>
>Content-Type: text/plain; charset="iso-8859-1"

>
>Hi all,
>
>I'd like to float the following idea: I was wondering if there is some
>interest in making ROS transport layer more modular (or maybe just
>improving the documentation on the current modularity and integration with
>the XMLRPC...).
>
>The rationale behind this idea is two-fold:
>
>- first, to make it easier to address the recurring questions about ROS
>not
>having transport X (replace X with shared memory, multicasting, morse
>code,
>land mail, ... ) or even using an other middleware for transport.
>
>- second, some companies have very good transport layers addressing issues
>such as real-time, quality of service, different medium,... but without
>the
>ecosystem of apps in ROS. It could be nice to offer a way to integrate
>these features. Maybe there is a link between this questions and moving
>towards an enterprise version of ROS.
>
>I'm not going to be pushy about these features, but I would be happy to
>contribute or coordinate a SIG if there is enough interest (and support
>from WG).
>
>--
>
>Cedric
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
></lurker/list/ros-users.html/attachments/20120523/05af3718/attachment-0001
>.html>