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

[Phil Dawes <philipd parallax co uk>]

Elliot Lee wrote:
> 
> On Fri, 18 Sep 1998, Phil Dawes wrote:
> 
> > Actually no. The IMR can determine that the client orb is an orbit orb
> > through the vendor profile in the request. It then calls the orb through
> > a proprietary interface telling it that there is a shared library
> > located at path X and the orb then loads it and activates it. The client
> > doesn't see any of this.
> 
> This is a VERY bad hack, and I am against having anything like this in
> ORBit. Why?
> 
> - Won't work in a network-transparent fashion. The IMR daemon could be
>   running on a different system than the client, meaning the IMR can't
>   know which plugins are installed on a particular system without
>   even more gross hacks.

It should be the IMR that handles the persistent shared library object,
and asks the orb to dlopen only if both are running on the same machine
(and using trusted objects etc..). 
If the IMR learns that the orb is on a different machine it could simply
open the shared library object in a wrapper executable and communicate
remotely.


> - Adds indirection needlessly, resulting in slowdowns and added
>   points of failure.

Yes, I ~agree with this. But there are optimisations which eliminate the
IMR if you already know about the object (multiple addresses, with last
one pointing to IMR).


> - Security considerations (letting a possibly remote computer tell you
>   that you should execute arbitrary code is a Bad Idea, and this will
>   also wreak havoc when the client is inside a firewall and the server
>   would not be able to open an IIOP connection back to the client).
> 

I believe the remote shared-library wrapper exe removes this problem.


> Loading a shared object is an application-side action. It should be
> initiated and performed totally in the application.
> 

I was looking at shared library objects as more of an optimisation over
standard objects rather then relying on them as a default behaviour. I
don't see any reason not to treat plugin 'shared library objects' as
simply corba objects which support a defined interface. Unless I'm
missing something the client should be able to use a corba object
without caring where it lives or how it is implemented.

I think that in the end everybody will write corba objects (including
plugins, application objects and services) as just 'objects' , and then
the orbs (and the users and installation routines which configure them)
will mediate the best way of composing an application from them. This
includes prescribing how they are linked up at runtime.

Cheers,

Phil.