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

List:       kde-core-devel
Subject:    Re: glib in kdesupport: yes or no?
From:       Havoc Pennington <hp () redhat ! com>
Date:       2003-03-10 19:41:01
[Download RAW message or body]

On Mon, Mar 10, 2003 at 12:10:52PM +0100, Antonio Larrosa Jiménez wrote:
> 
> Wasn't there a dcopc binding somewhere in kdesdk or kdebindings to use dcop 
> from C applications without linking to Qt?
> What's the reason of reimplementing dcop instead of using/improving/working 
> on that library? I suppose there's a reason if it was Matthias idea, but I 
> don't see it.
> 

Partially it is diplomacy, no question; it's hard to sell DCOP to
GNOME without giving GNOME developers a chance to affect its
design. Most shared specs have taken a "be open to changes from either
project" approach for that reason. If you read GNOME lists, you'll see
that selling D-BUS to GNOME isn't the easiest thing in the world.
On the GNOME lists, there's this same thread only about why we don't
use IIOP as the wire protocol, etc.

Making it more fun, I'm also wanting to use D-BUS as a systemwide
message bus for "plug and play" hardware etc. This introduces a lot of
security issues, and means we're trying to please people outside of
just GNOME/KDE.

Anyway, in general I tend to write code rather than try to move
people's religions, it's just easier. ;-)

There are some technical differences, among them:

 - D-BUS uses SASL for authentication and transport encryption, 
   so you theoretically have better security and integration with 
   things like Kerberos.

 - I gather that libICE is widely felt to be insecure (not safe when
   the peer is untrusted). So is bad for connections from a user to a
   systemwide daemon, or for TCP connections between machines.

 - there are apparently some other ICE weirdnesses people have
   mentioned (something about order in which protocols are registered
   breaking things, for example?)

 - plain-C-library with GLib/Qt wrappers.

 - as part of the desire to use D-BUS securely as a systemwide daemon,
   it is handling out of memory errors, instead of simply exiting as
   GNOME and KDE apps normally do.

 - also as part of that, there are resource limits and so forth on
   clients.

 - I'm trying to be religious about keeping things async/oneway, 
   so that apps aren't having to do too many round trips to each 
   other, especially at startup time.

There are also various smaller design differences.

So far no one has really advocated/documented using the DCOP wire
protocol (or IIOP), so there has not been a ton of discussion about
those options. Diving into some of the details might be interesting,
ideally some more DCOP experts could jump on message-bus-list and post
a good writeup.

Havoc

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