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

List:       kde-core-devel
Subject:    Re: RFC: DBUS & KDE 4
From:       Maks Orlovich <mo002j () mail ! rochester ! edu>
Date:       2004-09-29 19:58:08
Message-ID: 200409291558.08691.mo002j () mail ! rochester ! edu
[Download RAW message or body]

> 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]. 

-Maks
[prev in list] [next in list] [prev in thread] [next in thread]