On the 2.0 front, I'm fully working on the new Data Flow work package.
This week, I paid a visit to the DFKI where Sylvain's pushing Orocos
into their robots. As one could expect, I returned with more questions
than answers, but It gave me the insight on how to proceed the next
month.

I merged Sylvain's patches locally, on top of all the changes we had
up till now. The way Sylvain implemented things solved a bunch of
problems in one strike. For example, the lock free data flow
algorithms no longer need to guess how many threads are going to
access it. They know, it's '2'. There's also a mechanism to avoid
unnecessary copies in the data flow when using images for example.
It's a bit experimental yet and needs documentation, heck, nothing is
documented yet in the manuals, but the API documentation is quite
fine. Sylvain and I will work some further on the data flow classes
once the namespace/directory shuffle is over.

Next to the 'basic design', there are two major issues open: toolkit
generation from user types and hard-realtime data flow.

1. Toolkit generation
The initial idea was to allow users to describe their data types in
idl, and let a tool generate the C++ classes and the toolkit library.
In a perfect world, we would be able to re-use current idl
parsers/code generators and just generate code from an abstract class
representation. But we came to the conclusion that this is a too
limiting approach. IDL can not represent any C++ data structure, and
we might be tied to using the CORBA classes instead of the std
stuff.The golden rule was that 'the transport shouldn't be a
dependency for the C++ types.' ROS and TAO violate this principle,
because they interweave the user's structs with their own functions,
and even base classes. The Type system we have is just better. It
doesn't touch the user type a single bit. We wanted to keep it that
way.

Fortunately there is a solution, and yes, once again it didn't come
from the 'sweet' emacs/eclipse guy but from the 'happy' vim guy. As
posted earlier on this list, Sylvain created a tool for generating
toolkits from C++ classes. What I didn't fully realize is that behind
this tool is a very powerful library, called 'typelib', hosted on
github http://github.com/doudou/typelib/tree/master . It's created to
do type analysis on any 'backend'. It currently understands C++ (to a
degree) but it could parse other formats/languages as well. This
information is then used by 'orogen' to generate the toolkits and the
CORBA bindings. Using this tool, we can automate and do what ROS and
CORBA failed to do: use the user's native type and let him decide on
transport lateron, without any extra cost. This allows data types from
any library you might use to be transported. There are some tricks
involved, but I'm sure we can smooth things out (swig might help us).
But even if the user decided on CORBA or ROS data types, typelib comes
to the rescue and could (given enough patches) integrate these as the
native types to use in the RTT type toolkits.

To summarize, these would be the 3 possible workflows for RTT 2.0 users

A.Using native C++ classes (RTT way)
MyClass.h -> orogen -> MyClass-toolkit.so + MyClass-toolkit-corba.so
The user uses MyClass from MyClass.h as the data type to use in his
Orocos components.

B. Using a ROS type
MyMessage.msg -> orogen -> MyMessage-toolkit.so +
MyMessage-toolkit-ros.so + MyMessage.h (generated by ros tools)
The user uses MyMessage from MyMessage.h as the data type to use in
his Orocos components.

C. Using an IDL type
MyStruct.idl -> orogen -> MyStruct-toolkit.so +
MyStruct-toolkit-corba.so + MyStructC.h (generated by idl tools)
The user uses MyStruct from MyStructC.h as the data type to use in his
Orocos components.

I didn't dare to propose full transparent interoperability C++ <-> ROS
<-> CORBA, but it might be a logical extension. For clarity, orogen
only supports A. today.

2. Real-time Data Flow using Xenomai
I have been probing the Xenomai list to find out which primitive could
be used in combination with real-time select(). The only candidate was
the Xenomai Posix message queue, provided that all threads that access
it are Xenomai threads (the case in RTT). Nevertheless, it is a bit a
freightning idea to rewrite the whole ORB thing in Orocos. It starts
with data flow and before you know it, we overshadowed CORBA 4. On the
other hand, we see currently no way on how to influence TAO's memory
allocation behavior and ask it nicely to use Posix message queues
(that would involve writing a new TAO transport, similar to COIOP, ACE
supports Posix Message queues).

I'm still keeping both options open, but I'll certainly implement a
proof-of-concept using pure Xenomai. We need to have something to look
at in order to be able to evaluate it.

Peter