Re: the GNORBA library

[Joerg Budischewski <joerg budischewski germany sun com>]

Hello Maciej, Hello Elliot

> > I think, we agree on that the only thing that prevents someone from using
> > oaf over iiop only is that one does not have the IOR of it. So I think it
> > would be a good idea to have something in the system that allows to get
> > the IOR easily (not only for UNO, but also for other orb vendors). In my
> > eyes, a command line tool would be sufficient.

[... Elliot]
> No, we don't agree. My first line was "People need to use 
> the OAF library." There's no reason that I know of why 
> the OAF library cannot be used directly, and good 
> reasons to do so.

> (This is a challenge to you to describe some use cases 
> that illustrate the problems that you are trying to solve.
> :)
For example : 
There is another orb bob, that offers DII and DSI 
and a nice scripting lanuage. The bob vendor has never even
heard of GNOME. There is a fanatic bob-freak ( that doesn't
even know, what C is and what linking means), who
installs bobs binarys into a GNOME system. He simply tells bob 
the IOR of the ORBIT typerepository and the IOR of oaf and
uses the scripting language to talk to OAF to startup 
GNOME servers.

[ ... Maciej ]
> It's not just the IOR (I think there is actually already an easy way
> to get that by looking in a defined place in the filesystem, will post
> more details shortly). The liboaf library also does additional work
> besides just making the CORBA calls.
Certainly it is nicer to use oaf library for convienience.

> The most significant examples of this are the code to auto-launch oafd
> if not already running and register it
I supposed, that the oaf is a daemon started at GNOME session startup (am 
I wrong ?). Of course, it would be more failsafe to use the oaf library ( 
when e.g. oaf crashes, but one shouldn't design on such failures in my 
eyes ).

>, and the code to activate
> shared-library objects (which inherently has to run on the client, not
> the server).
This would be a lack certainly.

> This brings up the interesting case of shlib CORBA objects. I think we
> may need an out-of-process proxy which could activate and host shlib
> objects for bridge purposes; this will also be useful for language
> bindings and things like Bonobo<-->KParts or Bonobo<-->XPCOM bridges.
Such a proxy would make sense in my eyes.

> However, I'd really like OAF to be usable mostly or entirely through
> CORBA. I will look at what it would take to make that work. The
> published CORBA interface may not be the same as the OAF internal
> CORBA interfaces.
That is certainly ok, of course there may be more features or convenience 
functions when using libofaf.so.

Merry Christmas,
Joerg