Re: the GNORBA library

[Joerg Budischewski <joerg budischewski germany sun com>]

> > 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.
Yes, the oaf seems to be exactly what I wanted to have. Wether we want to 
support gnorba or not will be probably a decision of product management.

>         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.
That is the code I was looking for.

>         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.
I also thought of this proxy solution, it is the cleanest way. However 
the rloc_file stuff  would be attractive, because this could be done 
really in a few lines of code (at last, the only thing I want to have is 
a stringified IOR). But if it is not guaranteed to stay compatible, we 
can't use it.

But what is with the argument, that a different orbvendor may want to 
access your repository ? Wouldn't it be a solution, to write the IOR of 
the oafd at some certain place on the filesystem, where it can be 
accessed by everyone ? Or you could offer a command line tool, that 
prints the IOR to stdout (this would be a proxy, everyone could use) ? 

Just an idea.

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

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

Thx to all for your help,

Joerg