On Wed, May 22, 2013 at 9:37 AM, Esteve Fernandez <esteve@apache.org> wrote:
Hi,

there doesn't seem to be a SIG for ROS comm protocols and APIs, so I'm
writing here anyway :-)

There is a ros-sig-ng-ros mailing list. There was some good discussion, but it has not been very active, lately:

 https://groups.google.com/forum/?fromgroups#!forum/ros-sig-ng-ros
 
I am cross-posting there to archive your message.

Following Dirk's talk about the future of ROS 2.0, I thought of
experimenting with alternate protocols for serialization and RPC. I
hacked together rosthrift [1], a package for using Apache Thrift [2]
as the transport for serialization and RPC, it generates code out of
Thrift definition files and integrates nicely with catkin.

I just added support for Python, but Apache Thrift supports many more
languages. Apache Thrift is being used by many open source projects
(HBase, Cassandra, Scribe, etc.) and unlike Protocol Buffers, it comes
with a full RPC framework for C++, Java, Python, Ruby, Perl and many
more. Disclaimer: I'm one of the developers of Apache Thrift, so I'm
clearly biased :-)

I also pushed a bunch of examples [3] that use rosthrift and txrospy
[4] that mimic the AddTwoInts example from the tutorial, but use
Apache Thrift instead of TCPROS, thus replacing much of the low level
networking code.

Is there something in the roadmap about the network stack for ROS 2.0?
I'd love to contribute! Maybe we could create a SIG and move any
discussion there.

Cheers.

1 - https://github.com/esteve/rosthrift
2 - https://thrift.apache.org/
3 - https://github.com/esteve/ros_beginner_tutorials
4 - https://github.com/esteve/txrospy
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users

I don't know of any definite decisions. 

There has been some discussion of using zeromq as a possible low-level transport framework. It may solve some, but not all, problems with the current TCP implementation. I've looked at it and been impressed, but lacking hands-on experience, would not want to make any strong recommendation.
--
 joq