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

[sopwith redhat com (Elliot Lee)]

On Tue, 15 Sep 1998 23:58:39 +0100 (BST), Felix Bellaby
<felix@pooh.u-net.com> wrote: 

>Elliot Lee writes:
> > >The IMR will NEVER be specified by OMG because that would break the 
> > >object model itself!! The IMR is essential so that the ORB knows the 
> > >implementations it is hiding from the object clients!!
> > 
> > The two are not at all exclusive, and are in fact contradictory. If the
> > IMR is so essential, why will it never be specified, and why hasn't it
> > already been specified?
>
>The way I understand the OMG object abstraction, the object client
>should be aware of the IDL interface and nothing else.

>The IMR is unspecified by the OMG because only the ORB is supposed to
>use it.

Says who?

>Any spec would unneccesarily limit the flexibility of ORB
>implementations and provide object clients with information about
>how objects are implemented that the object abstraction is supposed to
>shield from them.

No it would not. It would provide servers with a standard way of registering
themselves for activation (the biggest thing) and a lot of other useful
operations.

>The IMR is needed by the ORB to associate the interfaces in the IR with the
>servers that implement them.

The interface repository is a way for accessing the data structures that
represent a .idl file. It doesn't interact with the imr at all.

>Any mechanism for getting from IR entries to the servers that support 
>them will do. It may be uncomfortable having to design a solution to 
>this problem but I doubt the OMG will ever do it for you.

It has nothing to do with being uncomfortable. If the implementation
repository always needs to do X, Y, & Z like you're telling me, why hasn't
the OMG said so?

> > And how do you expect the ORB to find out about this plugin, by using
> > dowsing rods on your filesystem? Until the OMG gives everyone an imr.idl
> > file, that's about the best way to do it.
>
>At some point in time the IDL for the plug-in was registered in the
>IR, since otherwise guile would be unaware of its existance.

Being aware of an interface does not require using the IR (and guile itself
is irrelevant to the question).

>process which registers this IDL can register the associated server in
>the IMR at the same time.

How does it do this? You said above that the IMR should have absolutely no
interface and only be accessable by the ORB, but here it's supposed to
register itself.

>Without a solution to the IDL to server translation then you are stuck
>with having the client find the servers. IMO that breaks the object 
>model and severely complicates the use of distributed services. This
>is much worse than implementing part of the internals of the ORB in a
>way which the OMG has yet to specify (and, IMO never will).

You're repeatedly misusing the term "IDL" with an unknown meaning, but one
that most definitely doesn't fit its official definition (Interface
Definition Language - the syntax/semantics of .idl files).

> > >The visiblity of implementations has left us with huge collections of
> > >modules for all our interpreted languages (python, perl, etc.). Hide
> > >the implementations behind the ORB and you only need one module:
> > >the module to access IDL!!
> > 
> > This doesn't have anything to do with the IMR. You are confusing the word
> > "implementation" in "Implementation Repository" with clients having the
> > ability to manipulate the details of an object implementation.  The latter
> > is not what was being referred to at all.
>
>I did not mean to create that impression. I see no role for the IMR
>in helping clients manipulate an object's implementation. I do not
>think clients should have any access to the IMR whatsoever.

Clients of the IMR do need to be able to register & unregister the object
implementations they provide, so access is required.

Obviously, clients of an object don't _care_ about the implementation
repository.

>IMO the IMR associates IDL with servers for the ORB.

Your opinion evidently doesn't have much to do with the facts.
Have you done any CORBA?

--------------------------------------------------------------
What GNOME already does:
1. Provide interfaces to allow programs to start & stop a server for
   a particular object type, and specify what type of activation
   will be used for that object (in-process or remote, possibly others)
   [baboon_get_factory(), baboon_Moniker_resolve() (NYF), gnome-name-service]
2. Provide a way for programs to find the address of an
   already-running server that wishes to advertise its
   implementation of a particular object type. [gnome-name-service]
3. Provide a way for binaries to register themselves as
   providing implementations of particular object types.
   [putting files in the right directory (NYF) and gnome_config]

And what will be will be.
--------------------------------------------------------------

There,
-- Elliot
Progress (n.): The process through which Usenet has evolved from smart
people in front of dumb terminals to dumb people in front of smart
terminals.  -- obs@burnout.demon.co.uk