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

[Phil Dawes <philipd parallax co uk>]

I'll answer this mail in two halves if that's okay - I've got to appear
like I'm working so I haven't got time to tackle the whole lot in one
go!

Elliot Lee wrote:
> 
> On Thu, 17 Sep 1998, Phil Dawes wrote:
> 
> > I don't think the clients should only have control over the lifecycles
> > of the servers at all. I think they may want to control the lifecycles
> > of the *objects* in some way, but shouldn't be able to say when a server
> > lives or dies.
> 
> 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.


> > Yes, you could do this as well, but the IMR additionally provides a
> > default lookup point for the orb if all else fails. The orb would look
> > for the object at the usual point (or points if the IOR contains many
> > addresses to try) - then if all else fails it will try the IMR (the last
> > address in the IOR - it won't actually know it's trying the IMR). The
> > IMR has the ability to check if the server is running and actually start
> > it if it's not.
> 
> Just thought of another problem with this TAO approach thing - it requires
> that POA object ID's be unique in a global namespace, instead of a
> per-server namespace.

Hmmm.. you may have a point there. I'll have a little think later.


> > > I don't want the client to be able to control how the object is
> > > implemented, I want them to be able to control how the object is accessed
> > > (same address space, remote calls, whatever), because the client knows
> > > what type of service it requires from the object, and therefore what
> > > access method is best.
> >
> > The client program doesn't have (and never will have) the power to
> > decide what access method is best - that is decided by the person who
> > writes the object.
> > What's the client program going to do - dynamically re-write an
> > executable object server as a shared library? ;-)
> 

> ORBit object implementations can be used as both same-address-space and
> remote implementations at the same time (and you can do fun things like
> pass an objref or IOR for an implementation in your address space to
> remote programs, and if you ever receive that objref back, the same
> address space calls will be used). 
Cool!

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

> 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 - looks like I
was wrong about the ORB not being able to change a server from an
executable to a shared library!



> [moved from above]
> > This isn't what I meant. The client doesn't 'activate the object' - the
> > IMR does (invisibly to the client and orb). However the person
> > registering the implementation with the repository needs to tell it how
> > to activate the object when the client requires it.
> 
> > I'm not keen on this idea of the client explicitly activating the
> > object. It doesn't give the client anything and it removes the
> > flexibility from the object developer.
> 
> You're wrong:
> 
> The program using an object (aka client, aka application) has the big
> picture of how that object will be used, how that object (aka
> implementation) will relate to other applications, etc. That knowledge is
> impossible for the object implementation to know, because a basic premise
> of the OO model is being able to reuse an object implementation.
> 
> The client knows exactly what programmatic context the object will be used
> in, so therefore the client is the only entity qualified to make the
> decision of how the implementation is activated.
> 
> Furthermore, I don't see how it _removes_ flexibility from the person
> writing the object implementation (which you mean by "object developer", I
> think). Elaborate...?
> 

I completely disagree. The client application doesn't have the big
picture - it only has the picture intended of it by the clients author.
Only the user of the program ultimately knows how he/she wants the
program to act. 

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.

Contrived example:
Say you have a spreadsheet application which uses a plugin to do some
calculation through an IDL interface. That plugin uses a simple
algorithm because it has to run on the same process.
Now suppose that after a while the user actually finds it needs a
version of the calculation which is much more precise, or uses extra
data from an outside field (e.g. a weather predictor calculation or
something). Say the calculation has to run on a Cray supercomputer
hooked up to some satelites (perhaps it's a service supplied by a
weather company). 
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!

This is actually not as contrieved as it sounds. Our company has
components which extend Excel far beyond what the microsoft developers
designed it for, but because they uses COM we have a great deal of
flexibility. 

Because of this accountants can do remote financial transactions
directly through their prefered spreadsheet application, and car
dealerships can have their customers choose the features for their car
directly on the page where the costs of the vehicle are calculated - the
information is provided direct from a vehicle configurator mainframe in
a different part of the country!

All of this can be done without the customer having any other client
software than vanilla Excel. The user simply configures the registry
with an entry for the remote component and then selects the component as
an embedded object within excel.
(Actually its more difficult than this because dcom is a bit shit, but
you get the idea)


More later...

Cheers,

Phil.