From kde-core-devel Mon Mar 10 19:41:01 2003 From: Havoc Pennington Date: Mon, 10 Mar 2003 19:41:01 +0000 To: kde-core-devel Subject: Re: glib in kdesupport: yes or no? X-MARC-Message: https://marc.info/?l=kde-core-devel&m=104732535221841 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