It makes my heart bleed seeing the various problems people have with setting
up a CORBA application with above average complexity. Especially when my mind
hears YARP people giggling and pointing at our pitty efforts. Then I was struck
by a 'copy what works' idea, which by definition had not much thought and will
probably release the hounds. Anyway.
What if we implemented the default corba transport by a byte sequence copy ?
Then only C++ type registration is required and for equal-endianess systems,
the structs are just copied ala YARP in preparation for network transport. (we
could let the TemplateTypeInfo
CORBA independent...)
My guess is 37 lines of additional code...? Or a small drup on a hot stove ?
Volunteers ?
Peter
Default CORBA transport implementation
On Monday 15 December 2008 11:00:55 Peter Soetens wrote:
> It makes my heart bleed seeing the various problems people have with
> setting up a CORBA application with above average complexity. Especially
> when my mind hears YARP people giggling and pointing at our pitty efforts.
> Then I was struck by a 'copy what works' idea, which by definition had not
> much thought and will probably release the hounds. Anyway.
Well, YARP is not better than CORBA as soon as people know what to do.
In the CORBA case, the only thing the user should have to write are type-to-
Corba::Type and Corba::Type-to-type conversions (plus the IDL). Nothing more.
I'm sorry the discussion at my lab does not go as fast as I'd like it to, but
the tool I have actually generates toolkits based on the C type definition
(making the whole process dead simple).
> What if we implemented the default corba transport by a byte sequence copy implement a 'byte copy' to
> ? Then only C++ type registration is required and for equal-endianess
> systems, the structs are just copied ala YARP in preparation for network
> transport. (we could let the TemplateTypeInfo
> void*, which is CORBA independent...)
I really hate this idea. Just having a way to simply provide the two
aforementionned convertion methods would be much much better (i.e. let people
*not* deal with Any).
Default CORBA transport implementation
On Dec 15, 2008, at 06:22 , Sylvain Joyeux wrote:
> On Monday 15 December 2008 11:00:55 Peter Soetens wrote:
>> It makes my heart bleed seeing the various problems people have with
>> setting up a CORBA application with above average complexity.
>> Especially
>> when my mind hears YARP people giggling and pointing at our pitty
>> efforts.
>> Then I was struck by a 'copy what works' idea, which by definition
>> had not
>> much thought and will probably release the hounds. Anyway.
> Well, YARP is not better than CORBA as soon as people know what to do.
>
> In the CORBA case, the only thing the user should have to write are
> type-to-
> Corba::Type and Corba::Type-to-type conversions (plus the IDL).
> Nothing more.
This is what we ended up doing for OpenCV images. Works fine and in
reality is straight forward conceptually, though I can't yet speak to
the performance (particularly with the large amounts of byte data
involved).
I definitely understand Peter's bleeding heart!! :-( Writing a CORBA
toolkit is definitely much harder than it should be, but most of our
problems (I would estimate about 2 full days of my time) were chasing
down seg-faults that were in no way correlated with the actual
problem. More documentation here might have helped, or further
examples, or just a better understanding (on my behalf) of what ACE/
TAO were doing under the hood (which is what we want to avoid).
Basically, the typenames that we registered were very slightly
incorrect. It worked fine for the OROCOS toolkit, but causes a
segfault in TAO about 20 functions deep. A real nightmare to chase
down, and definitely something we don't want less experienced
programmers trying to deal with (read PhD students, as I think Herman
mentioned). We've added some additional debug output to OROCOS that I
will send a patch in for soon.
My 2c
S
Default CORBA transport implementation
On Mon, 15 Dec 2008, Sylvain Joyeux wrote:
> On Monday 15 December 2008 11:00:55 Peter Soetens wrote: implement a 'byte copy' to
>> It makes my heart bleed seeing the various problems people have with
>> setting up a CORBA application with above average complexity. Especially
>> when my mind hears YARP people giggling and pointing at our pitty efforts.
>> Then I was struck by a 'copy what works' idea, which by definition had not
>> much thought and will probably release the hounds. Anyway.
> Well, YARP is not better than CORBA as soon as people know what to do.
>
> In the CORBA case, the only thing the user should have to write are type-to-
> Corba::Type and Corba::Type-to-type conversions (plus the IDL). Nothing more.
>
> I'm sorry the discussion at my lab does not go as fast as I'd like it to, but
> the tool I have actually generates toolkits based on the C type definition
> (making the whole process dead simple).
>
>> What if we implemented the default corba transport by a byte sequence copy
>> ? Then only C++ type registration is required and for equal-endianess
>> systems, the structs are just copied ala YARP in preparation for network
>> transport. (we could let the TemplateTypeInfo
>> void*, which is CORBA independent...)
> I really hate this idea. Just having a way to simply provide the two
> aforementionned convertion methods would be much much better (i.e. let people
> *not* deal with Any).
I agree... Keeping the information about the _meaning_ of the bytes is a
Good Thing To Have(TM), especially in the wider "model driven engineering"
wave of things, on which we want Orocos to ride in the near future....
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Default CORBA transport implementation
On Monday 15 December 2008 12:22:31 Sylvain Joyeux wrote:
> On Monday 15 December 2008 11:00:55 Peter Soetens wrote:
> > It makes my heart bleed seeing the various problems people have with
> > setting up a CORBA application with above average complexity. Especially
> > when my mind hears YARP people giggling and pointing at our pitty
> > efforts. Then I was struck by a 'copy what works' idea, which by
> > definition had not much thought and will probably release the hounds.
> > Anyway.
>
> Well, YARP is not better than CORBA as soon as people know what to do.
If I'm not mistaken, the difference in learning curve is huge. It's that aspect
I wanted to tackle. If we could explain someone that adding custom types is as
easy as writing
types()->addType("MyClass"); // creates TemplateTypeInfo...
We'd be in better shape.
> > What if we implemented the default corba transport by a byte sequence
> > copy ? Then only C++ type registration is required and for
> > equal-endianess systems, the structs are just copied ala YARP in
> > preparation for network transport. (we could let the TemplateTypeInfo
> > implement a 'byte copy' to void*, which is CORBA independent...)
>
> I really hate this idea. Just having a way to simply provide the two
> aforementionned convertion methods would be much much better (i.e. let
> people *not* deal with Any).
That was the intention of my idea, not letting the user deal with any's (and
even opening a door to ICE, which would force us to using byte sequences).
Maybe code speaks better ?
Does your tool allow to choose between the 'fast' byte sequence copies versus
the safe 'Idl-to-Any' copies ?
Peter
Default CORBA transport implementation
> > Well, YARP is not better than CORBA as soon as people know what to do.("MyClass"); // creates TemplateTypeInfo...
>
> If I'm not mistaken, the difference in learning curve is huge. It's that
> aspect I wanted to tackle. If we could explain someone that adding custom
> types is as easy as writing
>
> types()->addType
>
> We'd be in better shape.
Even with YARP you still need to marshal it yourself into the YARP "bags" (or
whatever their name is). You can't avoid that if you want to remain typesafe.
> > > What if we implemented the default corba transport by a byte sequence implement a 'byte copy' to void*, which is CORBA).
> > > copy ? Then only C++ type registration is required and for
> > > equal-endianess systems, the structs are just copied ala YARP in
> > > preparation for network transport. (we could let the
> > > TemplateTypeInfo
> > > independent...)
> >
> > I really hate this idea. Just having a way to simply provide the two
> > aforementionned convertion methods would be much much better (i.e. let
> > people *not* deal with Any).
>
> That was the intention of my idea, not letting the user deal with any's
> (and even opening a door to ICE, which would force us to using byte
> sequences). Maybe code speaks better ?
>
> Does your tool allow to choose between the 'fast' byte sequence copies
> versus the safe 'Idl-to-Any' copies ?
It was doing it but it does not anymore. The problem is simple: you'll need to
have both sides of the communication to agree on the way of marshalling thing
*or* you need two methods per data transfer (like push(Any) and
pushUntyped(vector
Btw, I looked at ICE and quite honestly I don't think you'll get anything from
it. It looks really just another CORBA now.
Default CORBA transport implementation
>> > Well, YARP is not better than CORBA as soon as people know what to do.("MyClass"); // creates TemplateTypeInfo...
>>
>> If I'm not mistaken, the difference in learning curve is huge. It's that
>> aspect I wanted to tackle. If we could explain someone that adding
>> custom
>> types is as easy as writing
>>
>> types()->addType
>>
>> We'd be in better shape.
> Even with YARP you still need to marshal it yourself into the YARP "bags"
> (or
> whatever their name is). You can't avoid that if you want to remain
> typesafe.
Bottles iirc.
> implement a 'byte copy' to void*, which is CORBA).
>> > > What if we implemented the default corba transport by a byte
>> sequence
>> > > copy ? Then only C++ type registration is required and for
>> > > equal-endianess systems, the structs are just copied ala YARP in
>> > > preparation for network transport. (we could let the
>> > > TemplateTypeInfo
>> > > independent...)
>> >
>> > I really hate this idea. Just having a way to simply provide the two
>> > aforementionned convertion methods would be much much better (i.e. let
>> > people *not* deal with Any).
>>
>> That was the intention of my idea, not letting the user deal with any's
>> (and even opening a door to ICE, which would force us to using byte
>> sequences). Maybe code speaks better ?
>>
>> Does your tool allow to choose between the 'fast' byte sequence copies
>> versus the safe 'Idl-to-Any' copies ?
> It was doing it but it does not anymore. The problem is simple: you'll
> need to
> have both sides of the communication to agree on the way of marshalling
> thing
> *or* you need two methods per data transfer (like push(Any) and
> pushUntyped(vector
That's not what I meant. I would only have push(Any), but, if no CORBA
transport is defined (plain old user struct is communicated), copy the
struct to a CORBA byte sequence and put that in the any. The other side
will still check the Orocos type name, *and* check the any conversion
*and* check the size of the sequence. So if by accident, one side
registered a custom CORBA transport and the other forgot, RTT is able to
detect this. The only thing we couldn't detect is really broken setups,
where both sides registered the same typename for a different struct,
which has the same size. To close this hole, we could use the
typeid.name(). In that case, we're equal safe as your linker (symbol size
+ symbol name must match).
Peter
Default CORBA transport implementation
On Dec 15, 2008, at 11:20 , Sylvain Joyeux wrote:
>>> Well, YARP is not better than CORBA as soon as people know what to("MyClass"); // creates TemplateTypeInfo... implement a 'byte copy' to void*, which is).
>>> do.
>>
>> If I'm not mistaken, the difference in learning curve is huge. It's
>> that
>> aspect I wanted to tackle. If we could explain someone that adding
>> custom
>> types is as easy as writing
>>
>> types()->addType
>>
>> We'd be in better shape.
> Even with YARP you still need to marshal it yourself into the YARP
> "bags" (or
> whatever their name is). You can't avoid that if you want to remain
> typesafe.
>
>>>> What if we implemented the default corba transport by a byte
>>>> sequence
>>>> copy ? Then only C++ type registration is required and for
>>>> equal-endianess systems, the structs are just copied ala YARP in
>>>> preparation for network transport. (we could let the
>>>> TemplateTypeInfo
>>>> CORBA
>>>> independent...)
>>>
>>> I really hate this idea. Just having a way to simply provide the two
>>> aforementionned convertion methods would be much much better (i.e.
>>> let
>>> people *not* deal with Any).
>>
>> That was the intention of my idea, not letting the user deal with
>> any's
>> (and even opening a door to ICE, which would force us to using byte
>> sequences). Maybe code speaks better ?
>>
>> Does your tool allow to choose between the 'fast' byte sequence
>> copies
>> versus the safe 'Idl-to-Any' copies ?
> It was doing it but it does not anymore. The problem is simple:
> you'll need to
> have both sides of the communication to agree on the way of
> marshalling thing
> *or* you need two methods per data transfer (like push(Any) and
> pushUntyped(vector
>
> Btw, I looked at ICE and quite honestly I don't think you'll get
> anything from
> it. It looks really just another CORBA now.
Agreed. I've used ICE on another project, and it is just a "prettier"
version of CORBA.
S
Default CORBA transport implementation
On Mon, 15 Dec 2008, Sylvain Joyeux wrote:
[...]).
>> Does your tool allow to choose between the 'fast' byte sequence copies
>> versus the safe 'Idl-to-Any' copies ?
> It was doing it but it does not anymore. The problem is simple: you'll need to
> have both sides of the communication to agree on the way of marshalling thing
> *or* you need two methods per data transfer (like push(Any) and
> pushUntyped(vector
LabComm from Lund is providing
automatic marshalling. They are working on a newer version, with realtime
capabilities over ethernet, and with even more support for compile-time
marshalling support. (And open source.)
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm