Re: getting started

[Havoc Pennington <rhpennin midway uchicago edu>]

On Wed, 26 Aug 1998, Miguel de Icaza wrote:
> 
> > In fact, I've found the biggest problem in trying to learn about this
> > stuff is: "OK, I know how to write Hello World.  What's a useful
> > design pattern for a desktop app?"
> 
> This is a good question.  
> 
> CORBA in the gnome desktop will be used in a couple of places:
> 
> 	- In the Baboon document model.  
> 
> 	  Baboon are a set of evolving CORBA interfaces for doing
> 	  OLE2-like compound documents.  These will be used in
> 	  container applications and embeddable applications.
> 
> 	- Automation facilities:  You export the API to your
> 	  application and let other application remotely invoke your
> 	  application to request services.
> 
> 	- General RPC mechanism (Gnothello/Panel are examples of
> 	  this). 
> 
> The baboon module on CVS includes a name service and a library to
> launch services on demand.  It needs some minor tweaking though
> 

I've looked at the 2.2 spec a little and some source and I got a couple of
books (I didn't have to pay for them :-). 
CORBA Distributed Objects Using Orbix does look useful and I picked that
one up.

I have some concrete questions for all you components experts, after
looking at this stuff just a little. 

 - is ORBit in its present state fast enough to use in place of shared
   libraries? i.e. how much performance hit do I take every time I go 
   via CORBA? 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.)

 - Miguel, in the stuff you list above it sounds like the model is
   "applications exporting services." 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.

   Basically what I would like to do is have "plot modules," which know
   how to do different kinds of plot. I guess these would be embeddable
   in a spreadsheet (or just in a window for Guppi's purposes). Ideally 
   they would have their own address space so as not to crash Guppi, and 
   could be written in any language. 
 
   Should this use CORBA or would a "plugin" approach be better?

 - 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"). I don't see the trading service in ORBit yet. Presumably 
   the naming service can be used instead if the Plot objects are 
   named in a consistent way? Can I ask for everything in the Guppi 
   context with "Plot" in the "kind" field? How does this work?

 - What would be involved in getting C++ bindings and is anyone working 
   on these? It looks like the idl compiler backend is around 4000 lines
   of code in ORBit and Mico both. What provisions does the main ORB make
   for other language bindings and how difficult is the task? (the
   interfaces implemented by the ORB itself have to be exported, right?)

Havoc