RFC: DBUS & KDE 4
bastian at kde.org
Wed Sep 29 15:51:46 BST 2004
[Don't reply if you haven't read the whole message]
[If you do not fully understand how DCOP or DBUS works, make sure to gain a
full understanding by asking meaningful questions BEFORE voicing an
uninformed opinion that makes you look like a fool . It will also keep you
off the kde-core-devel auto-reject list.]
I would like to discuss how KDE 4 is going to support DBUS. There are a few
different possibilities here, several requirements of varying hardness and
all this is constrained by what is actually technically possible.
Technically DBUS provides roughly the same capabilities as DCOP. This is not
suprising given that DBUS is modelled after DCOP. The main advantage is that
DBUS is more widely accepted outside KDE which makes it a good candidate for
a) communication between KDE applications and the underlying operating system
b) communication between KDE and non-KDE applications.
Especially a) is a good point for supporting DBUS since the Unix OS has
historically been rather bad in informing non-root user space about what is
going on in the system. Lately we have solutions like libfam and DNotify on
Linux that both have their own notification mechanisms. Having a widely
accepted single IPC mechanism for information like this in the form of DBUS
would make it easier to export information from the kernel or root-based
system services to non-root user space which in turn will make it easier for
KDE to write KDE applications that integrate better into the operating
b) is also a point of consideration. If we want Unix/Linux to play a
significant role on the desktop we will need to provide Independent Software
Vendors (ISVs) with a single set of standards. If we can establish DBUS as
_THE_ Unix/Linux IPC standard we can use it as part of other standards. It
will also make it easier to let non-KDE applications integrate into the KDE
For the above reasons DBUS is very interesting technology, and there is
significant demand for DBUS support from KDE application developers. As such
there is no doubt that DBUS will be used in the near future by KDE
applications. Thanks to the Qt-DBUS bindings  that will even be easy.
The question for KDE then becomes how we are going to support DBUS in relation
to DCOP. The main concern here is backwards compatibility.
There are several approaches, some of them really good, some of them really
bad, some of them perfect but not feasible.
1) Provide DBUS support in addition to current DCOP support, keep the two
2) Provide DBUS support, deprecate DCOP, convert at runtime all DCOP IPC to
DBUS to provide 100% backwards compatibility.
3) Replace DCOP with DBUS, provide no compatibility.
4) Replace DCOP with DBUS, adjust dcopidl to generate DBUS code instead of
5) Something better :-)
I will now discuss the various approaches. This is the part where I would like
to receive informed feedback on.
1) We also get this if we don't do anything. Applications will start to use
the Qt-DBUS bindings anyway. It's a bad situation because developers and
users will start to get confused about which form of IPC to use. The good
thing about it is that we keep full DCOP-backwards-compatibility.
2) This sounds like the perfect solution, but is it feasible? It seems to me
that conversion of the call arguments may be impossible in cases where the
argument types are application defined. Due to the way DCOP works, it is only
possible by the receiving and sending applications in such case to separate
the different arguments. As such, such calls will always look different from
a native DBUS call with the same arguments. Is that a problem? In which
situations would that cause compatibility issues? Can those be solved in
3) When I talked about really bad approaches I ment this one. We MUST provide
as much backwards compatibility as possible if we want people to consider KDE
as a serious and stable platform. Every script with "dcop kdesktop
KScreensaverIface lock" out there that we break means making the KDE platform
less attractive for both end-users and ISVs alike. It will result in a bigger
number on every Microsoft sponsored study out there under "TCO". And the
really bad thing is that they would actually have a point with that.
4) This is the 95%  solution. I think it's easy to pull off and 95% of all
code would never notice the difference. The 5% will mostly be KDE 3
applications that run in a KDE 4 environment. But as I explained above, that
5% is still too much. Is there something that we can do to solve the issue
for this 5%?
5) This space has been intentionally left blank for your proposals ;-) 5) is
the one we will actually implement ;-) It will probably be an enhanced
version of either 2 or 4 or both.
 All quoted statistics are 100%  made up.
 I pity the fool.
bastian at kde.org | Wanted: Talented KDE developer | bastian at suse.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel