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.

http://lists.kde.org/?l=kde-core-devel&m=109647249214611&w=2

It seems to me that conversion of the call arguments may be impossible in cases where the argument types are application defined. This is possible via QMetaType and the custom D-BUS type, I use this trick to transfer more complicated stuff in my accessibility bridge.

http://lists.kde.org/?l=kde-core-devel&m=109647624715773&w=2

nope, there's no glib dependency. The API is a bit glib-ish, but we don't care since we do not expose it in our wrapper.

http://lists.kde.org/?l=kde-core-devel&m=109647353013165&w=2

KDE 4 applications would then be reachable with "DCOP over DBUS" and "DBUS" and exisiting code that makes (hand coded) DCOP calls in KDE would use "DCOP over DBUS" while dcopidl in KDE4 would generate "DBUS" calls. For KDE 3 compatibility we could extend the dcopserver to change DCOP calls to DBUS clients into "DCOP over DBUS" calls. The dcopserver would then be an optional server in order to obtain KDE3 compatibility.

http://lists.kde.org/?l=kde-core-devel&m=109647704712328&w=2

i have a draft for a new systray spec that resolves the insanity of the current one. as it stands it relies on DBUS, since it provides certain things (e.g. Message Busses) that DCOP doesn't which are needed for something like the systray. so... it's coming. it's just that DBUS is so relatively new that adoption is only beginning.

http://lists.kde.org/?l=kde-core-devel&m=109647746222090&w=2

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.

http://lists.kde.org/?l=kde-core-devel&m=109647859323328&w=2

See, that's partly why I am really uncomfortable about this stuff. It's 90% buzz, 10% technology. And buzz has rather circural nature: people get convinced that everyone will use X, so everyone ends up using X. D-BUS hardly excites me because I don't see anything particularly innovative in it (while DCOP's very existance was quite a radical idea, and the whole key/call causality tracing things is interesting). D-BUS seems mostly like DCOP rehashed by someone who didn't know DCOP and ICE very well, so ended up making some things worse w/some things better, while reproducing a lot of the really mundane stuff.

http://lists.kde.org/?l=kde-core-devel&m=109656030004288&w=2

the question has be posed, but not answered: can the "stuff that is worse" be fixed and how much effort would that take? i know earlier you spoke about deadlock issues, can you point to where these problems exist exactly[1]?

http://lists.kde.org/?l=kde-core-devel&m=109656225322586&w=2

That said, D-BUS offers all that I wanted when I started hacking on the command-line dcop client and much more, so I'm obviously strongly in favour of it.

http://lists.kde.org/?l=kde-core-devel&m=109667224532163&w=2