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

[Elliot Lee <sopwith redhat com>]

On Fri, 18 Sep 1998, Phil Dawes wrote:

> > When I was talking about a server, from the client's point of view the
> > only connection is that object reference. Servers and objects are
> > inextricably intertwined, because from the client's view, the one provides
> > the other.
> 
> Yes, but a server may serve many objects to a range of different
> clients. The client should only have to be aware of the object reference
> its using, not the server its running on.

The client is aware that if it has an objref, it has a line of
communication to the object implementation aka the server.

(This sounds like arguing over syntax, let's ferget it. I'm perfectly
aware that the client doesn't know the PID or host or port of the server
process:-)

> > Once a process has activated an object
> > implementation with the POA and gotten an objref for it from the POA, the
> > location of the object is transparent as far as same address space vs.
> > remote calls.
> 
> Which is why it would be extra good for the client to be able to
> activate the object implicitly without specifying its location.

The point was that you don't give up any transparency as far as being able
to use the object from anywhere. How does this make it a better idea to
transparently create the object?

> > It is entirely feasible to allow the executable file to be dlopen()'d and
> > used just like an implementation inside a shared library, and it is even
> > easier than that to make a ten line wrapper around a shared library
> > implementation that turns it into a standalone server.
> > 
> 
> Yes I've thought about this too - That would be fantastic. I didn't know
> it would be possible to dlopen an executable files though

Foot in mouth, on my system (something that looks like RHL 5.1)  glibc's
dlopen() SEGV's when given /bin/ls as a filename. On Solaris, I get:

[sopwith@centaur ~] ./tt
error loading bin/pb: ld.so.1: ./tt: elf error: /bin/ls: not a shared or
relocatable object

So the idea was basically ok, but it won't work using available
interfaces.

> The client program being explicit about how it activates the object
> actually impeeds re-use - it stops the user from being able to make this
> decision without having to resort to code.
...
> With the IMR approach the user could just change the entry for the
> plugin to point to the object running on the cray and away you go!

If you read my paragraphs about the activation methods and all,
gnome_get_object_list() will just read in the user's activation
configuration file, see the weather predictor listed as "relay", and
then contact the name service to find the object.

In other words, the client will be able to make suggestions and give hints
as to what it thinks are good ideas, and the user will also be able to
give hints & suggestions & settings. Although I didn't bring it up, I
agree that the user should have control, and it is already taken into
account as far as the gnome setup goes.

-- 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