From kde-core-devel Wed Sep 29 16:24:07 2004 From: "Ian Reinhart Geiser" Date: Wed, 29 Sep 2004 16:24:07 +0000 To: kde-core-devel Subject: Re: RFC: DBUS & KDE 4 Message-Id: <36623.66.92.236.216.1096475047.squirrel () 66 ! 92 ! 236 ! 216> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=109647521514506 Thiago Macieira said: > Ian Reinhart Geiser wrote: >>Against DBUS: >>a) More glib (someone please get these guys the Thinking in C++ book) > > I don't think this point is an issue. The wire format for D-BUS is > defined. > So we can write our own libkdbus library if we so wish, with C++ bindings. > Technically you can do the same thing with DCOP, but its not pretty. The wireformat though being open and documented is a plus. > It would be necessary to have a library anyways if my idea of a DCOP alias > inside D-BUS is to be followed. > >>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. > > That someone else would be us. Putting the KDE weight behind it could give > the momentum it needs. DCOP and MCOP are largely KDE-exclusive. > But there where C only bindings for both. MPlayer and Xine both have arts backends. I am not sure if they use Qt at all though, I just know that they will use arts if its running. Personally I think the kernel guys adopting this will make this all a reality, so this will become less of an issue as time goes on. IMHO its something to be aware of. >>For DCOP: >>c) Bindings > > That doesn't have to go away. Ideally if the API stays the same its not a horrible issue. But its still an issue that needs to be addressed. 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.