Re: On GIMP and CORBA



Elliot Lee writes:
 > On Thu, 20 Aug 1998, Felix Bellaby wrote:
 > 
 > > CORBA supports the dynamic linking of implementation code into the
 > > address space of running executables as part of the standard. Systems
 > > without dlopen do not fully support CORBA. I suppose you could add
 > > memory sharing into the stubs and skeletons on those systems.
 > 
 > The CORBA spec doesn't say _anything_ about dlopen or dynamic linking.

OK, my mistake. The CORBA spec is directed towards ensuring that ORBs
can talk to one another rather than considering how ORBs might talk to 
themselves. However, dynamic linking of libraries is available in mico 
using the ActivateLibrary ActivationMode in the ImplementationDef
within the ImplementationRepository. Since this is very useful as a
means of communicating between plugins it would be a great shame if
ORBit was to fail to implement it and leave it up to the client code
to handle these cases. (Systems without dynamic linking can just leave
these servers out of their ImplementationRepository).

The purpose of CORBA is to hide the problem of how an object is
implemented from the developer/user. This is best achieved when
operations like dlopen calls are implemented within the ORB. Providing 
an ORB which only talks the most generic language available means that 
no one will use CORBA unless they need to talk accross processes. This 
means they need to use multiple mechanisms for achieving similar
operations. This takes us back to the existing situation in the GIMP.

So, I think what I said was in the spirit of CORBA if not in its letter.

Felix



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]