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

[Elliot Lee <sopwith redhat com>]

On Fri, 18 Sep 1998, Phil Dawes wrote:

> > If the IMR is a daemon, though, that totally excludes using
> > same-address-space object implementations. You must have the IMR inside
> > the client ORB in order to load implementations from shared libraries, and
> > there goes your premise byebye.
> 
> 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.
- Adds indirection needlessly, resulting in slowdowns and added
  points of failure.
- 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).

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

> Yes, I think you might be right there. Actually no, the POA object ID
> only needs to be unique in the IMR.

Ahh yes, you're right there. That's still going to be a pain though.

> > You must have some sort of standard directory listing of object references
> > of objects that wish to advertise their availability to service requests
> > for a specific interface. (See below)
> 
> Yes, but you don't want to have each and every one also responsible for
> activating the objects if they are not running at the point the user
> wants to use them.

Instead we should have the IMR responsible for this. Uh huh. Makes lots of
sense to have two programs doing the work of one.

> I suspect that that functionality is in the name-service because thats
> the first service that got finished.

No, actually I wrote gnome-name-service from scratch just because it was
the first interface that came to mind as far as activating servers goes.

> > I'm not convinced that gnome-name-service is the best place for storing
> > information about servers that can be started. For example, it doesn't
> > allow a client to choose between multiple implementations of the same
> > interface, and doesn't allow the same address space object
> > implementations.
> 
> IMR provides scope both of this (in conjunction with other services ;-).
> It's nifty because it decouples the activation from the lookup, so these
> services don't have to handle activation of the objects recorded in
> them.

Something has to do activation of servers. Arguing that it is a better
idea for the IMR to do it than the name service just because the name
service does something else as well (lookup) doesn't make sense to me.

> > Most likely what should be done is to write a spec for storing information
> > on the available implementations and the ways they can be accessed. Then a
> > libgnorba routine will exist to read that information in and provide it to
> > the application, and another routine to activate an implementation with a
> > specified type and activation method.
>
> Hmmm... What does this actually give you over an IMR? With an IMR the
> user is free to tweak the activation policies of the objects
> him/herself.

It allows multiple servers to list themselves as providing the same
interface. (i.e. you can have three GNOME::WordProcessor programs
registered, and then the client can show a list of those three to the user
if it wishes, and find out which spreadsheet impl they want).

It allows complete tweaking of the activation policies on a per-machine
basis (which is where it is more likely to be needed) rather than a
per-GNOME session basis (which the IMR would be by the sound of it). This
also means that a client wanting to load a WTGROMT component from a shared
library will be able to get the list of WTGROMT-compliant components
according to what is installed on a machine, and present it to the user.

It allows retrieving meta-information about an object (the human-readable
description, the list of activation methods, etc.) which will make it much
easier to write object system administration programs.

It allows private server activations - a client can start up a server for
its exclusive use, instead of having the IMR LOCATION_FORWARD all clients
to a server just because that server was started by the IMR.

> Yes but you're still specifying an activation 'routine'. This routine is
> proprietary to baboon/ORBit. I'm saying you don't need a routine at all
> - you can have a corba object to do this (the factory), and have it
> activated implicitly upon use using the IMR. Surely this is better than
> a proprietary activation routine - systems other than gnome can create
> gnome objects and use them.

Non-GNOME programs won't be aware of the GNOME-specific interfaces
anyways.

> > Not necessarily. You don't want this "if it's a shared library, it just
> > happens magically". For example, you might want to run the same
> > application on a really fast system and a really slow system. On the fast
> > system, you obviously want the implementation loaded as a shared library,
> > but on the slow system, it might be faster to talk over the network than
> > do the computations on the local system.
> 
> Exactly. 
> Hmmm... So does the give_me_a_factory() function take the "shlib" arg as
> a hint, not a command?

It is part of the equation that determines the end result of
give_me_a_factory(), the other part being the system config file that
lists all the objects and their possible activation methods.

> > Providing mechanism in libraries, and leaving the policy up to the
> > application, is a big part of what I am arguing for.
> 
> Providing mechanism in libraries, and leaving the policy up to the
> *user* is what I'm arguing for ;-)

The user will not manipulate the activation methods of objects directly.
They will start up their word processor and trust it to do all the magic.

The network administrator will be free to edit their gnome-corba.conf (or
whatever) file and change the listings of servers so the activation
methods tend towards their preference.

> Object by value is one way of doing object migration (albeit a heavily
> flawed one IMHO). What I meant was the users ability to replace one
> implementation of the object with another (possibly remote) one without
> upsetting, recoding (or touching) the client app.

This will be just LOCATION_FORWARD support, nothing to do with the IMR
necessarily.

> But with an IMR you can write a gnome printing server which gets
> activated on demand, regardless of whether the client is gnome oriented
> or not.

How will a client support the GNOME printing interface if it doesn't know
anything about GNOME? Clients that do know about GNOME will have libgnorba
around to use. bzzt.

> > AFAIK, using factories or not is orthagonal to using an IMR.
> 
> But activating your 'root' level factories is not. (i.e. the factories
> you use to bootstrap your first transient objects)

I don't see what you mean here.

> > (Relying on a well-known port is a Bad Idea - you've instantly limited the
> > flexibility of your system as far as "scalability and transparency". ;-)
> 
> But the point was that I've regained it by leveraging the IMR as a back
> up plan if the ORB can't find that object at that host/port . I'm still
> waiting for a better solution to this ;-)

I was speaking of the IMR, not the object impl.

Unless you run the IMR on a well-known host:port, you can't have these
magic "persistent" object references that fall back to contacting the IMR,
because the host:port encoded in the IOR will have to always be valid in
order for the IOR to be truly "persistent".

> Okay. (still need to use proprietary 'get_factory' though)

Instead of a proprietary IMR approach, gasp shock horror.

> Dick's expressed an interest in doing this. Anyway, I don't see how your
> 'get_factory()' call can be made from any orb - its not on a corba
> interface (and if it was, you'd still need a way of bootstrapping it).

You're going to need a way of bootstrapping the IMR too if you run it as a
separate daemon (assuming you don't want to run it on a well-known
host:port - pick your poison). Bootstrapping is simpler with the libgnorba
approach - just call a library routine and it does the server activation
work directly (while still allowing you to pass off activation to a remote
object if you so wish).

FWIW nothing is stopping you from putting up a web page with a package
that does transparent distributed enterprise-level component <insert
buzzwords> activation, or sending in patches for ORBit to implement
related functionality like LOCATION_FORWARD. (No gross "server tells
client to load a shared library" hacks though :-). Since you say that you
need your view of an IMR implemented for your specific application, others
may likely need it too. I just disagree with the way your activation
method works, and don't think it is a good idea for ORBit to standardize
on anything at all (the ongoing debate means that _somebody_ isn't going
to like what gets put in, and ORBit can definitely meet a goal of CORBA
2.2 compliance without it). Furthermore, the points above hopefully
outline why I think it's a bad idea for use in GNOME.

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

irc://irc.mint.net:6666/#gimp