Re: IMRs again (was Re: Comments on the baboon plugin spec)

[Elliot Lee <sopwith redhat com>]

On Wed, 16 Sep 1998, Felix Bellaby wrote:

> This binding model is great for providing quick and flexible access to 
> binaries and running processes without storing persistent data. (:

Persistent data doesn't have anything to do with the method a client uses
to obtain an object reference to the object that it wants to use.

> Mico has to maintain a fully stocked persistent IR and IMR in order to 
> expolit these advantages.

(And that is a maintenance overhead that comes into the picture and can
cause problems. In any case, Miguel has good ideas on populating the IR,
so he will wind up doing part of that :-)

> This produces a scripting language that grows automatically as new 
> interfaces are registered. Furthermore, this same trick works
> simultaneously with all extensible scripting languages, saving the
> need to create modules that link each one to each new interface.
> Therefore, the added costs of implementing the IR and IMR are
> recovered many times over (once per scripting language). 
> 
> The slight delays in obtaining object references relative to the 
> GNOME model are unimportant with scripting languages.
> The slight increase in the time required to install servers is easily
> outwieghed by the greater access made available by installing into the
> IR and IMR as well as installing into the GNOME CORBA server
> directories.

(a) Speed is _never_ unimportant.
(b) The things you are talking about happen exclusively on the client
    side using the IR, and don't have anything to do with the
    IMR. The ability of a client to use DII on an object with
    a specific interface has naught to do with the way an object impl is
    created.

Still didn't answer my earlier question about your CORBA experience,
-- Elliot
"In film you will find four basic story lines. Man versus man, man
 versus nature, nature versus nature, and dog versus vampire."
    - Steven Spielberg