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

[Felix Bellaby <felix pooh u-net com>]

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. 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. The IMR is needed by the ORB to associate the 
interfaces in the IR with the servers that implement them. 

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. 

 > >One advantage of plug-ins defined as CORBA objects is the language
 > >independence of IDL. Put together a means of accessing IDL dynamically 
 > >from guile and every user can use every plug-in from within every
 > >gnome app without the app programmer knowing anything about it. Put 
 > >together a decent IMR and the user does not even have to install the 
 > >plug-in: the ORB can fetch it when it is needed.
 > 
 > 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. The
process which registers this IDL can register the associated server in
the IMR at the same time. This would typically happen when the plug-in 
was installed but could happen before its installation providing the 
IMR was told how to do the installation.

The baboon libraries could provide the interfaces to install plug-ins
in this fashion just as easily as providing interfaces for loading the
plug-in servers. If you are worried that OMG might come up with an IMR
specification in the future then you do not have to call the data
store that holds the interface->server mapping the "IMR".

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

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

IMO the IMR associates IDL with servers for the ORB. Once you have
that association then a mechanism for accessing IDL gives you a means
of accessing servers. Thus, instead of having a module that loads a 
library and wraps its C functions using perl, you have a perl wrapper 
for IDL and accessing the IDL loads the library via the ORB.

Felix