Re: IMRs again (hopefully the last one!)

[Phil Dawes <philipd parallax co uk>]

Elliot Lee wrote:
> 
> On Fri, 18 Sep 1998, Phil Dawes wrote:
> 
> > > 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.

Making the default installation of components and their activation
policies up to the word processor installer.

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

Ditto with an IMR. 


> > 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 without a default point-of-call you still need to leave a server in
the old position (to recieve the request and send a LOCATION_FORWARD).
Why not let that server be an IMR (i.e. have an activator as the default
last-point-of-call address for all persistent objects)?



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

What if they're windows machines? Or any other architecture that doesn't
have gnome on it? With straight CORBA they can use idl and the IR to
find out about the object, and then use it. 



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

I mean that using an IMR can replace 'get_factory()' (your root level
factory getter) with a corba-compliant technique for creating transient
objects from nothing: 
1) Look up the factory objref in a corba service, 
2) use the factory (implicitly activated by the IMR), 
3) get the ref to the created transient object from it

Any client running on any orb on any architecture can do this.
Hell, get_factory() can even be a wrapper for this!


> > > (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".
> 

This is true. And here ladies and gentlemen, is where we hit a real
problem with corba IMRs. If you move the IMR, you must also change all
the persistant IORs connected with it.


> > Okay. (still need to use proprietary 'get_factory' though)
> 
> Instead of a proprietary IMR approach, gasp shock horror.

:-D
- you know what I'm going to say here - FOR THE CLIENT THERE IS NO
PROPRIETARY IMR APPROACH - THE OBJECT IS ACTIVATED IMPLICITLY UPON USE!


> > 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 :-).

We'll save this argument for another day ;)

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

Hey, don't credit me with the idea. ORBix, Visibroker, IBM
Component-Broker, SOM and Mico all do this as well!

> 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

I thoroughly agree with this point of view. This is one of the reasons
why linux will rule the world - it doesn't force users to do *anything*,
least of all adhere to a standard that isn't right for them! The only
true standards which emerge are where people can't do any better on
their own - true implementation democracy.

> and ORBit can definitely meet a goal of CORBA
> 2.2 compliance without it).  

But ORBit will never be able to support corba persistent IORs without
it. Dick's already said that he'll be implementing an IMR for ORBit for
this reason.

As for gnome, there's no reason why we can't do both: where necessary
get_factory() becomes a helper function for persistent factory objects
which use an IMR.

I'll be putting up a web page with the abridged for/against stuff on
IMRs, get_factories() and activating name services as a way of ending
this paper trail. 
I'll mail you when I'm done and you'll be able to point out where I've
mis-represented you ;-)

Cheers - this has been really helpful,

Phil.