Re: the GNORBA library

[Michael Meeks <michael helixcode com>]

Hi Joerg,

On Fri, 15 Dec 2000, Joerg Budischewski wrote:
> 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 ?

        For the next stable release: Gnome 1.4; currently edging towards
release, due in Jan / Feb we will start using CORBA seriously. This will
co-incide with the introduction of OAF ( which is now in a freeze for
Gnome 1.4 ). Consequently the correct choice of activation framework,
pretty much whatever the question, is OAF. Nothing except the Panel uses
gnorba any more, ie. evolution, nautillus, gtkhtml, gnumeric,
guppi3, eog, gnome-db, sodipodi, glade, libglade etc. use _only_
OAF. Furthremore OAF fixes multitudinous brokenness and limitation in
gnorba. Please target OAF.

> I really don't want to reimplement the server activation
> part of oaf or gnorba ( you did a good job at it ).

        You need to look at copying oaf/liboaf/oaf-registration.c I would
imagine, particularly oaf_server_by_forking and the rloc_file* code,
however relying on internal implementation details of oaf is
extraordinarily evil IMHO.

> 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) ).

        Well; to insulate against this you might have a small proxy that
you can control that talks to OAF; the IOR of which you can get via. some
process that you control and that will not change. This will incur extra
latency on activation; c'est la vie.

> 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 ).

        Hmm; I don't see this as a serious problem, once we release OAF
for Gnome 1.4 we commit ourselfs to the API which may be extended but will
maintain binary compatibility wherever humanly possible ad-infinitum
et-nauseum.

> 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.

        Fair enough; whilst there is an ORBit version for windows, I think
there isn't for mac etc.

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

        Fair enough not to I suppose; a good-ish solution might be to have
an external activation proxy as suggested; otherwise you have to copy oaf
internals which may change.

> Is there a possibility to startup CORBA servers just over IIOP ?

        Well; you can communicate with oaf once you have it's IOR via it's
CORBA interface see oaf/idl/oaf.idl, this is probably what you want to do.

> 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 ).

        Well; assuming that you want to interact primarily with GNOME
CORBA interfaces, none of these use multiple inheritance, and I see no
reason why they should, and I can see why UNO doesn't allow it :-) so I
think this is no problem.

        Regards,

                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot