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

List:       kde-core-devel
Subject:    Re: RFC: DBUS & KDE 4
From:       "Ian Reinhart Geiser" <geiseri () yahoo ! com>
Date:       2004-09-29 15:40:55
Message-ID: 35355.66.92.236.216.1096472455.squirrel () 66 ! 92 ! 236 ! 216
[Download RAW message or body]

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.

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

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

Cheers
  -ian reinhart geiser
--
--
+-Ian Reinhart Geiser geiseri@sourcextreme.com
+-Vice President of Engineering
+-http://www.sourcextreme.com
+-It's not that we don't make mistakes, we just don't keep them around.

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