Maks Orlovich mo002j at mail.rochester.edu
Wed Sep 29 20:58:08 BST 2004

> For DBUS:
> a) Someone else will maintain the foundation.

What happens if they quit? Is anyone here willing to take the lib over in that 
case? (I sure as heck am not)

> For DCOP:
> a) Tons of code and documentation on how it works.
> b) Relatively bug free
> c) Bindings
> d) As far as i know most if not all known security holes have been worked
> out.

Well, DCOP hasn't really been used in a security-sensitive setting.

> Against DCOP:
> a) Basicly we are stuck in our own world unless some how everyone decides
> DCOP is a good idea.
> b) IPC between users is sketchy at best.  In theory it should work, but
> its a pain in the ass.

Well, first of all, we currently  have user + display pairs be endpoints. 
Shouldn't be too hard to use an alternate auth module for that, though

> c) Dealing with Qt types in a QDataStream is annoying outside of Qt.
> Doable, but annoying.

Bah, not too hard. See kdenonbeta/lyod/dcop/dcopmessages.h

> d) Libice is the work of the devil, and is completely unmaintained.

..except there is also libLYOD, which is just the work of the annoying and 
loud-mouthed me (which is, to be fair, missing the server bits, but they're 
not hard, and the lib is tiny)... [and I am not sure whether the code of 
libICE or of libdbus sucks more. The former is a long-dead dialect of C, but 
well-commented and doesn't pretend the programmer is a C++ compiler]. 


More information about the kde-core-devel mailing list