From kde-core-devel Wed Sep 29 15:40:55 2004 From: "Ian Reinhart Geiser" Date: Wed, 29 Sep 2004 15:40:55 +0000 To: kde-core-devel Subject: Re: RFC: DBUS & KDE 4 Message-Id: <35355.66.92.236.216.1096472455.squirrel () 66 ! 92 ! 236 ! 216> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=109647249214611 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.