RFC: DBUS & KDE 4

[Waldo Bastian]

On Wednesday 29 September 2004 17:40, Ian Reinhart Geiser wrote:
> I guess I have been more on the "lets use dcop" vs "lets develop dcop" end
> of things so I have some perspectives.  For the record I am still not for
> or against either approach yet.  I do have some desires for KDE 4's IPC
> but that is it at this point.
>
> For DBUS:
> a) Someone else will maintain the foundation.
> b) Its maintained (although i hear maksim has a libice impl of his own)
> c) Unified IPC w/ other linux desktops
> d) IPC between users, and with the OS is simplified. (although I'm not
> convinced of security issues yet)
>
> Against DBUS:
> a) More glib (someone please get these guys the Thinking in C++ book)
> b) No-one has really adopted it yet.  I think HAL uses it to a limited
> extent, and maybe gconf is maybe moving to it?  It all looks like someone
> is waiting for someone else to bite.  This didn't turn out so well with
> DCOP or arts.
> c) We have a fairly good knowledge of DCOP, do we want to abandon
> something that works.
>
> 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, it helps that we disabled TCP access. But as you will see in this 
thread, TCP access is one of the things people actually like to see in.

DBUS better facilitates things like TCP access in the sense that the idea is 
to have two separate DBUS'es. One for inter-user communication (system) and 
one restricted to a single user only (the DCOP model). Everything you attach 
to the system DBUS creates security concerns, which is in one way a bad 
thing, some of these concerns will prove to be actual security problems. And 
a good thing, because all services attached to the system DBUS are supposed 
to be designed with security in mind, so when you grant TCP access to the 
system DBUS it should not imply instant shell access.

That's one of the main reasons why TCP in DCOP is disabled, if you get access 
somehow you basically have a login shell. (The other one is lack of 
encryption, but that would have been easy to add.)

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

The fact that the dcop command line tool supports making calls to other users 
is one big hack, not a supported feature.

> c) Dealing with Qt types in a QDataStream is annoying outside of Qt.
> Doable, but annoying.
> d) Libice is the work of the devil, and is completely unmaintained.

The devil part is true but it is not entirely bad. Also with the new X.org it 
would actually be feasible to get some features in there. One problem is that 
libice is a standard part that comes along with X servers. (isn't it ironic?) 
That makes it hard for people with old crappy X servers to install a recent 
version from e.g. X.org, by shipping our own copy as part of KDE we can at 
least be sure that everyone has the right version.

> These are broad points as I see them.  Currently I am leaning to the
> approach of a plugable IPC service.  One that can support things like
> Rendevus, XMLRPC, SOAP, and desktop IPC.  

I think it's important to keep the remote stuff well-separated from the 
desktop-only stuff. Maybe we should have a third DBUS dedicated to remote 
services.

> The other thing I want more than 
> anything else is a lightning fast local single session, single user IPC by
> default.  If dbus can do this( i have not ported my dcop benchmark tests
> to dbus yet so i cannot answer this) great, otherwise I think we might
> wish to look into this more.
>
> DBUS is great for things like "new disk in drive" or "camera plugged in",
> but the largest usecase we have in dcop right now is "is this app
> running?" and other communication between applications on a single
> session.  I still have not seen answered if dbus can fit both of those
> scenarios effectively.  Waldo,Harry,Havoc please point me to some numbers
> if I am horribly off here.

It would be nice to have some comparison data on performance indeed. I don't 
see any particular reason why DBUS would need to be any slower than DCOP, the 
main task of both is to move data into and out of a pipe. The connection part 
may show significant differences wrt performance though, depending on the 
kind of authentication/authorisation that is performed. We definitly need to 
gather data on that.

Cheers,
Waldo
-- 
bastian at kde.org  |  Wanted: Talented KDE developer  |  bastian at suse.com
  http://www.suse.de/de/company/suse/jobs/suse_pbu/developer_kde.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040929/88f38b2f/attachment.sig>