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:
> > 
> > Elliot Lee wrote:
> > >
> > > 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.
> 

But if you also have a Trader which activates persistent objects, and a
'get me an object with this interface on this display' service which
activates persistent objects, and a set of baboon get_factory() api
calls which activate persistent objects surely you've now got lots of
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.
> 

See above. I think you'll have to get use to the concept of many loosely
coupled objects working together to fulfill a larger function - that's
what this distributed objects thing is all about and the benefits are in
scalability and reuse. Sort of like the difference between shared
libraries and static ones, the point is that the IMR gets reused 100
times over as you add more and more services which support persistent
objects.

Cheers,

Phil.