RFC: DBUS & KDE 4

[Waldo Bastian]

[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 [2]. It will also keep you 
off the kde-core-devel auto-reject list.]

Hi,

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

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

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 [3] 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 
worlds separate.
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 
DCOP.
5) Something better :-)

I will now discuss the various approaches. This is the part where I would like 
to receive informed feedback on.

DISCUSSION
=======

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 
another way?

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% [1] 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.

Cheers,
Waldo

[1] All quoted statistics are 100% [1] made up.
[2] I pity the fool.
[3] http://trolls.troll.no/~harald/dbus/
-- 
bastian at kde.org  |  Wanted: Talented KDE developer  |  bastian at suse.com
  http://www.suse.de/de/company/suse/jobs/suse_pbu/developer_kde.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040929/9af753ff/attachment.sig>