Re: getting started

[Miguel de Icaza <miguel nuclecu unam mx>]

>  - is ORBit in its present state fast enough to use in place of shared
>    libraries? 

No.  Right now ORBit only supports servers which are running in a
different address space.  ORBit needs to get support for implementing
servers as shared libraries: those servers when activated will be
dynamically linked into your application.

> i.e. how much performance hit do I take every time I go via CORBA?

I have not measured it, but the latency of an ORBit call is going to
be in the range of a typical context-switch, I suggest we keep our
CORBA usage to non performance critical tasks until shared-library
servers are implemented in ORBit.

> What exactly happens in terms of executables, libraries,
>    etc. when I use ORBit? (I'm finding the complete lack of implementation 
>    details in the CORBA spec and books kind of disconcerting.)

There are various approachs to connect CORBA clients and servers.  The
simpler one is to use the CORBA_ORB_object_to_string and
CORBA_ORB_string_to_object (which convert a CORBA object reference
into a string and viceversa).  This is what the panel does and what
Gnothello does.  This of course has scalability problems.

Here is where the Baboon factory-launcher/name-server enters the
game.  I dont remember the routine name, but the idea is that you
request an object to be launched and you get back a nice Object
reference to it.  

This "launching" so far is limited to starting the server program
process and wait for the server program to register with the name
service.  

Dick has stated that he wants to implement the TAO implementation
repository approach (which I am inclined to think is better than our
current setup).

> Does ORBit also provide a way to
>    build the application up out of lots of small objects? That is, I would
>    like Guppi to be lots of modules loaded on demand, rather than a huge
>    app exporting a zillion services. Though of course it could *appear*
>    to be a huge app to users and other apps and that's fine.

Well ORBit will just do the communications bits for you.  

But to answer your question: yes, you can make Guppi just be
gazillions of different servers.

>    Should this use CORBA or would a "plugin" approach be better?

CORBA can be used as the communications channel for the "plugin"
approach:-).

>  - Ideally the plot modules would be discovered at runtime, without
>    requiring a recompile of Guppi's main executable. It sounds to me 
>    like the "trading service" does this ("give me a list of all Plot 
>    objects"). 

Well, my plan in this regard was to abuse the naming service, and
register all of those servers under:

	"/GNOME/Servers/Guppi/*"

And then enumerate the registered servers.

>  - What would be involved in getting C++ bindings and is anyone working 
>    on these? 

I dont think is working on those yet.  I am told that there are two
different C++ bindings:  one that uses every single new feature of C++
and is pretty non-portable and another one which is more conservative
and more similar to the C bindings.  They are documented in the OMG
documentation.

Miguel