Re: IMRs again (was Re: Comments on the baboon plugin spec)
- From: Chad Maloney <opercmm rosevc rose-hulman edu>
- To: Elliot Lee <sopwith redhat com>
- CC: gnome-components-list gnome org, orbit-list cuc edu
- Subject: Re: IMRs again (was Re: Comments on the baboon plugin spec)
- Date: Thu, 17 Sep 1998 11:58:14 -0500
Elliot Lee wrote:
>
> On Wed, 16 Sep 1998, Felix Bellaby wrote:
>
> > This binding model is great for providing quick and flexible access to
> > binaries and running processes without storing persistent data. (:
>
> Persistent data doesn't have anything to do with the method a client uses
> to obtain an object reference to the object that it wants to use.
Aha! You just defined the naming service. The naming service's job is
to be the method a client uses to obtain an object reference to the object
it wants to use.
The naming service hands the client a reference to an object. The naming
service doesn't know if it is running or not or whether it can even
be successfully started if needed. The naming service is DNS. DNS
doesn't know if the machine on the other end is up, it just lets you
easily name machines so you don't have to use numbers.
The ORB then recieves a call on the reference that the client has. It
is the ORB's job to dispatch this call. This is where the IMR comes in.
The ORB/IMR pair needs to decide if this object is currently activated
and if not, start it. After all is said and done, it all must boil down
to either we can't access the object and we raise a System Exception
or the call goes through.
Elliot, it seems you want to drop the IMR and instead have the lookup
in the naming service ensure the object is started. In this case,
ORB knows the object is started because the client must have talked
to the naming service in order to get a reference. This is okay,
I guess, but we should still have an IMR (and the Naming Service
should be able to be used without the extension) for people who
want behavior that way.
I agree that the ORB/IMR line is not drawn in the spec. I don't
know why it isn't. Maybe it is to allow leeway in implementing.
Does the IMR have a record of all activated objects or is that
the ORB. If the ORB does, the IMR only needs to be able to
startup objects that the ORB knows is not running. If the
ORB doesn't, it just sorta dispatches requests to the IMR
and the IMR returns the forward and then you just talk to the
object. To me, both those are valid.
Elliot, if you don't want to work on the IMR, that's fine. If
you want to concentrate on baboon and how Gnome will use ORBit,
that's fine. But be open to the idea of having the IMR for
people who want to use it. I think we have a chance to write
a really great IMR that handles shared library/collocated
objects in a very slick way.
Of course all this is my opinion on things. Standards
disclaimers apply. By default, I'd listen to Elliot and Dick
because they have done a lot of the work already.
- Chad
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]