RFC: DBUS & KDE 4
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
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