[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Future of DCOP
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2001-03-26 14:18:35
[Download RAW message or body]

   Hi!

On Mon, Mar 26, 2001 at 01:50:41PM +0200, Matthias Ettrich wrote:
> I've done some thinking about DCOP recently, under the lights of the ongoing 
> problems with libICE on platforms other than Linux and the fact that it's 
> unmaintained.
> 
> Thinking about alternatives, there are really just two options, ORBit and 
> MCOP. 
> 
> Given that MCOP is meant for multimedia and that we eventually will have to 
> or want to utilize ORBit anyway in the future for all kinds of desktop 
> cooperation (accessability, session management (XSMP over ORBit rather than 
> ICE), network directory services, ...), I'd like to evaluate porting DCOP 
> over to ORBit as underlying communication layer. 

I think the ultimate goal should be one unified object space for components
and types. Basically, if you have client to that unified object space, you
should be able to talk to an

 * KBackgroundIface
 * Arts::SoundServer
 * Bonobo::Stream

with the same primitives (i.e. for instance via stubs). Getting this done will
involve writing at least two gateways, that is two of

 * MCOP <-> CORBA
 * DCOP <-> CORBA
 * DCOP <-> MCOP

which eventually means we'll need to use ORBit (or our own IIOP implementation)
somewhere anyway. There are some things that are quite different, like

 * reference counting and asynchronous streams in MCOP
 * signals in DCOP
 * the way the system defines types/interfaces (DCOP: C++ marshalling/dynamic
   querying of interfaces only, CORBA/MCOP: idl files ; interface repository)
 * handing of unicode
 * exceptions (CORBA: yes, DCOP/MCOP: no)
 * difference between in/out args (CORBA: yes, DCOP/MCOP: no)
 * component registry / activation service / naming service
 * ... and probably a lot more ...

But eventually, gating MCOP/DCOP to CORBA and using this a middle layer seems
to be a reasonable way to go.

> The only technical problem I see right now is for the 
> DCOPServer to safely detect when a client goes down. I hope this is solvable, 
> if not by adding something to ORBit. I haven't checked this yet.

MCOP has distributed reference couting for this. All objects need to be
referenced to be used. MCOP removes the references to objects once a client
dies (it can detect this easily, as the socket will produce an error, then).

CORBA by definition doesn't allow you to solve it that way, because it allows
clients to dynamically build up the TCP connection as needed. But well, there
might be a workaround (which then might not be CORBA standard, but if it
works).

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         

[prev in list] [next in list] [prev in thread] [next in thread]