OmniORB support for CORBA

I rebased my work on Peter's latest master, so if you want to try out the
omniorb thing, you can get it there:

git://github.com/doudou/orocos-rtt.git

There are probably things that has been lost in the process, so if you have
problems building it, please tell me.

OmniORB support for CORBA

On Friday 19 December 2008 16:46:26 Sylvain Joyeux wrote:
> I rebased my work on Peter's latest master, so if you want to try out the
> omniorb thing, you can get it there:
>
> git://github.com/doudou/orocos-rtt.git
>
> There are probably things that has been lost in the process, so if you have
> problems building it, please tell me.

Thanks. I had ported your effort as well and got TAO/omniorb working. Then my
harddisk crashed and burned. And my 1-day old backup excluded .git and .svn
directories. And then I freaked out.

Thanks for contributing, I'll see if your patches are along the same lines as
what I could save from the burning wreckage. These caveats I could remember:

* data ports+CORBA unit tests needed to cast result to (int).
* AnyConversionHelper needed to be adapted (took reference to different type,
solved this with extra template parameter)
* rtt-corba-config.h (or whatever) was nowhere used
* I hate the -DCORBA_IS_TAO define at compile time. Needs to be in the above
config file (or rtt/corba/corba.h)
* Some problem with the exception printing in TAO a missing '()' in the
corba.h file

Peter

OmniORB support for CORBA

> * data ports+CORBA unit tests needed to cast result to (int).
For TAO you mean ?

> * AnyConversionHelper needed to be adapted (took reference to different type,
> solved this with extra template parameter)
I had an ambiguity resolution problem that shows up on 32bit (I developped this
patch on 64bit where everything was fine). If that was your problem as well, it
is fixed on the current github version.

> * rtt-corba-config.h (or whatever) was nowhere used
Not in RTT, but it can be used by other packages to detect which version of
CORBA is used. For instance, I have an Orocos/Ruby bridge that requires OmniORB
to be used.

> * I hate the -DCORBA_IS_TAO define at compile time. Needs to be in the above
> config file (or rtt/corba/corba.h)
Will do (I personally don't care)

> * Some problem with the exception printing in TAO a missing '()' in the
> corba.h file
Will fix.

OmniORB support for CORBA

Any updates here ?

I'm about to create the 1.8 branch. Although I'd love to have OmniORB in there
for many reasons, the uncertainty regarding these issues (ie backwards
compatibility with the existing TAO usage) is holding me a bit back. There's
enough improvements in RTT to justify 1.8, so omniorb is not a show-stopper
for that version... just let me know.

Peter

On Monday 22 December 2008 22:35:14 Sylvain Joyeux wrote:
> > * data ports+CORBA unit tests needed to cast result to (int).
>
> For TAO you mean ?
>
> > * AnyConversionHelper needed to be adapted (took reference to different
> > type, solved this with extra template parameter)
>
> I had an ambiguity resolution problem that shows up on 32bit (I developped
> this patch on 64bit where everything was fine). If that was your problem as
> well, it is fixed on the current github version.
>
> > * rtt-corba-config.h (or whatever) was nowhere used
>
> Not in RTT, but it can be used by other packages to detect which version of
> CORBA is used. For instance, I have an Orocos/Ruby bridge that requires
> OmniORB to be used.
>
> > * I hate the -DCORBA_IS_TAO define at compile time. Needs to be in the
> > above config file (or rtt/corba/corba.h)
>
> Will do (I personally don't care)
>
> > * Some problem with the exception printing in TAO a missing '()' in the
> > corba.h file
>
> Will fix.

OmniORB support for CORBA

On Thu, Jan 22, 2009 at 10:46:30AM +0100, Peter Soetens wrote:
> Any updates here ?
>
> I'm about to create the 1.8 branch. Although I'd love to have OmniORB in there
> for many reasons, the uncertainty regarding these issues (ie backwards
> compatibility with the existing TAO usage) is holding me a bit back. There's
> enough improvements in RTT to justify 1.8, so omniorb is not a show-stopper
> for that version... just let me know.

I have absolutely no time for it ... So, sorry, but it will have to
wait.

Sylvain

OmniORB support for CORBA

Sylvain Joyeux wrote:

I rebased my work on Peter's latest master, so if you want to try out the
omniorb thing, you can get it there:

git://github.com/doudou/orocos-rtt.git

There are probably things that has been lost in the process, so if you have
problems building it, please tell me.

Does the OmniORB CORBA layer supports RTAI? I don't know much about CORBA, but I guess the CORBA Layer has to be RTAI compliant to garantee hard real time behavior.

OmniORB support for CORBA

On Monday 22 December 2008 15:03:29 philippe [dot] hamelin [..] ... wrote:
>

Sylvain Joyeux wrote:

I rebased my work on Peter's latest master, so if you
> want to try out the omniorb thing, you can get it there:
>
> git://github.com/doudou/orocos-rtt.git
>
> There are probably things that has been lost in the process, so if you have
> problems building it, please tell me.
>

>
> Does the OmniORB CORBA layer supports RTAI? I don't know much about CORBA,
> but I guess the CORBA Layer has to be RTAI compliant to garantee hard real
> time behavior.

There is no Open Source CORBA implementation that is hard real-time, at least
when doing inter-process communication (due to path optimisations, in-process
CORBA calls can be made real-time).

Peter

On the TAO website, they

On the TAO website, they state in bold : Real-Time CORBA with TAO. So this is soft real-time ? Can we say that it's "more" real-time then OmniORB or the latter is as "real-time" as TAO is?

On the TAO website, they

On Tue, Dec 23, 2008 at 02:03:59AM -0000, philippe [dot] hamelin [..] ... wrote:
> On the TAO website, they state in bold : Real-Time CORBA with TAO. So
> this is soft real-time ? Can we say that it's "more" real-time then
> OmniORB or the latter is as "real-time" as TAO is?

TAO is far from being hard real time. Anyway, the whole CORBA spec makes
having it real-time very hard (pun not intended), as there are dynamic
memory allocation everywhere (as, for instance, when you unmarshal from
Any, something RTT do).

As for the TAO-vs-OmniORB thing. YMMV, but I know people who were
anti-CORBA because of TAO change their mind with omniORB. My own
preference comes to omniORB *not* because of performance issues (as I
have no real numbers here ...), but because omniORB is much easier to
maintain (as: compile yourself, sometime it is needed and very hard to
do for TAO) and because people I know use it for robotic applications
*and are happy about its performance*, and -- finally -- because you
don't pay a few MB of shared libraries just to get the basic features
in.

But again, this is a completely subjective decision on my side and I
never quote me saying that TAO is crap.

OmniORB support for CORBA

On Dec 19, 2008, at 10:46 , Sylvain Joyeux wrote:

> I rebased my work on Peter's latest master, so if you want to try
> out the
> omniorb thing, you can get it there:
>
> git://github.com/doudou/orocos-rtt.git
>
> There are probably things that has been lost in the process, so if
> you have
> problems building it, please tell me.

Does anyone have enough experience yet with Orocos and OmniORB, to
speak of the differences compared to CORBA? The first things that come
to mind are:
- the complexity of writing plugins (or is it identical?)
- runtime performance and overhead
- reliability

TIA
S

OmniORB support for CORBA

Well, we use Arch Linux.
OmniORB is readily packaged for this distro.
TAO is not, and compiling it yourself takes like ages and is rather involved.
So I am very pleased to see this alternative for TAO!

Cheers, Theo.

OmniORB support for CORBA

On Friday 19 December 2008 16:59:52 S Roderick wrote:
> On Dec 19, 2008, at 10:46 , Sylvain Joyeux wrote:
> > I rebased my work on Peter's latest master, so if you want to try
> > out the
> > omniorb thing, you can get it there:
> >
> > git://github.com/doudou/orocos-rtt.git
> >
> > There are probably things that has been lost in the process, so if
> > you have
> > problems building it, please tell me.
>
> Does anyone have enough experience yet with Orocos and OmniORB, to
> speak of the differences compared to CORBA?
OmniORB is a CORBA implementation... It is just less huge and bloated than
TAO.

Sylvain

OmniORB support for CORBA

On Dec 19, 2008, at 14:07 , Sylvain Joyeux wrote:

> On Friday 19 December 2008 16:59:52 S Roderick wrote:
>> On Dec 19, 2008, at 10:46 , Sylvain Joyeux wrote:
>>> I rebased my work on Peter's latest master, so if you want to try
>>> out the
>>> omniorb thing, you can get it there:
>>>
>>> git://github.com/doudou/orocos-rtt.git
>>>
>>> There are probably things that has been lost in the process, so if
>>> you have
>>> problems building it, please tell me.
>>
>> Does anyone have enough experience yet with Orocos and OmniORB, to
>> speak of the differences compared to CORBA?
> OmniORB is a CORBA implementation... It is just less huge and
> bloated than
> TAO.

Does that translate to less workload on the CPU (and network)?
S