From kde-core-devel  Mon Mar 10 19:45:07 2003
From: Havoc Pennington <hp () redhat ! com>
Date: Mon, 10 Mar 2003 19:45:07 +0000
To: kde-core-devel
Subject: Re: glib in kdesupport: yes or no?
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=104732559422139

On Mon, Mar 10, 2003 at 01:22:10PM -0500, George Staikos wrote: 
>     Are you open to a complete redesign of D-BUS if KDE users decide that it 
> is not usable in its current form?

Yes, certainly. However as I said the sooner the better; if I can hear
people's concerns this month I can probably implement lots of the
changes myself, if I hear the concerns in 4 months most likely I won't
be able to. But someone else might be able to, it's not like I'm the
only person here who can write code. ;-)
 
> > An important question for KDE is, *if* you were going to use it in
> > addition to or instead of or as a backend for DCOP, how would that
> > migration work, and how would the code be set up.  e.g. would you a)
> > swap out the DCOP backend, replacing libICE; b) introduce a new API
> > enough like DCOP to be easy to port to, but different from DCOP; c)
> > keep both DCOP and D-BUS as separate things; or d) some combination of
> > those or something else. We can design D-BUS to make each of these
> > paths easier or harder.
> 
>    I spoke with a few KDE developers about this too.  I suspect we will have 
> to make a bridge between DCOP and D-BUS, keeping DCOP around for backward 
> compatibility.  If D-BUS lives up to expectations, hopefully it would become 
> the new internal API and mechanism for KDE with DCOP apps being bridged over.  
> Having two separate, unintegrated RPC mechanisms is a bit silly.  This is 
> IMHO of course.  We have to make sure that D-BUS is at least as easy to use 
> for the developer as DCOP is.  That means the API must easily support calls 
> and signals the way we have them now.  Some of this will be our own 
> responsibility of course.

My belief is that the API from a KDE standpoint should be virtually
identical to DCOP. That's the current plan anyway.
 
>    As do I.  I don't however believe in change for the sake of change.  It 
> really needs to provide tangible benefit to KDE.  One thing we really could 
> use is better secure, remote support.  DCOP is rather lacking in that area 
> right now.  Unfortunately DCOP is really not network enabled the way the rest 
> of KDE is.

Right. I think better security, the systemwide mode, and simply the
benefits of interoperability (such as sharing accessibility code
without having to use GLib/CORBA) might be important benefits for KDE.

Havoc