Re: the GNORBA library

[Joerg Budischewski <joerg budischewski germany sun com>]

> > I have heard from a new object activation framework (oaf), that is
> > currently under development, but I couldn't find any documentation on it
> > on gnome.org. Are there informations somewhere ?

[ JP Rosevear ]
> It is available from cvs and in fact all newer version of bonobo use it
> rather than gnorba.

I downloaded the packages from www.gnome.org/start/installing (the base 
libraries and the CORE package). A find . -name '*gnorba*' found a lot, 
while a find . -name '*oaf*' found nothing. Certainly, this is only a 
guess, but I had the impression, the oaf is not used in this version.

However, OpenOffice of course would also like to be interoperable with 
existing GNOME installations, if this is possible with a considerable 
amount of work. (In my eyes, lots of 'normal' users get frustrated when 
they install software B, that requires a newer version of software A).

So I would be interested, will there be a hard switch sometime later (no 
gnorba, only oaf) or will there be two concurrent activation frameworks 
on one system ? When is oaf scheduled to appear in a stable release ?

[Michael Meeks]
>It is quite possible, if you want to re-implement chunks 
>of liboaf duplicating code and creating a maintenance 
>nightmare. Why is it that youdo not want to link to ORBit 
>/ liboaf ? these are not huge libraries. This would be 
>my preferred solution. 
I really don't want to reimplement the server activation 
part of oaf or gnorba ( you did a good job at it ).

However we would prefer communicating via IIOP instead of 
directly using ORBIT libraries for a number of reasons :

1.) Runtime decoupling
Either OpenOffice code and GNOME code is going to change 
( that's software =:o) ).
We will not be able to synchronize our stable drops. So
there may always be difficulties with newer versions of 
Software A and older versions of Software B. I want
to reduce the probability, that such problems occur, to 
an absolute minimum.
Symbols in C-libraries are far more likely to change
than idl-interfaces and IIOP. It is in general easier
to deal with the latter changes ( e.g. new interfaces ).

2.) Platform independence :
We want to have a CORBA bridge that runs also 
on other platforms (e.g. windows). Therefor we want to 
limit platform dependent code to an absolute minimum.

3) Build decoupling
Integration of other libraries into our build enviroment is 
certainly possible, but bears also problems and needs to be
maintained in future (even when the bridge is long ready 
and stable). 

In an ideal world, I would retrieve the namingservice IOR 
somehow (this will stay system dependent), then I could ask for
an implementation repository to get IORs for a desired service.
I know, in CORBA, there is no implementation repository 
interface specified ( I think it is a major lack in CORBA, 
that they did not specify at least a minimal interface ), 
so for each ORB, one needs to adapt to a different interface, 
but that's still easier than linking against a specific ORB 
library.

Think of a different ORB vendor, who wants to access GNOME
services. Does he also need to link against GNOME libraries
to be able to do this ? Are there then two orbs running in 
one process ? What is about the duplicate symbol 
problem on unix ( ORB_init is certainly quite popular
in the CORBA world).

If there is no other possibility, we will certainly link
against orbit libraries, but it would be better not to
do this.

Is there a possibility to get the NamingService IOR somehow without the 
GNORBA library ?
Is there a possibility to startup CORBA servers just over IIOP ?

>In your comparison I am slightly confused by the i l u-umlaut 
>syntax for tabulating feature comparisons; can 
>you enlarge on this ? 
This is a bug (On windows with german locals, it looks 
great :o) ). This is fixed now (make sure to press the reload
button of your browser once).

>There are good arguments for only adopting single inheritance
>within Gnome's use of CORBA.
Yes, in the beginning, we want to support only single
inheritance, because GNOME does not use this. 
However in my eyes, for a good CORBA bridge, 
also multiple inheritance must be supported somehow ( though 
we really don't want to support it natively in UNO ).

Regards,
Joerg