Thiago Macieira thiago at kde.org
Fri Dec 23 15:30:49 GMT 2005

Hello All

I'd like to get the discussion on KDE4's IPC started. I'll try to separate 
my personal opinion and preference from consensus and facts (I'll post my 
opinion in a reply shortly).

According to our Goals page (http://wiki.kde.org/KDE+4+Goals), our options 
for the IPC system are:

Of the three, only two have seen some work: the DBUS one on 
branches/work/dbus-kde4/ and the DCOP one on trunk. However, Waldo's work 
on DBUS stopped roughly 5 months ago, as he found himself with other 
responsibilities. Discussing on IRC with Kévin Ottens and David Faure has 
led to some ideas, but which require testing to be proven. In essence, 
the idea is that we can probably address our problems with some sane 

The DCOP port started entertaining the possibility of maintaining 
backwards compatibility with KDE 3's wire format. Hence, *all* uses of 
QDataStream must contain a call to setVersion. This is proving to be 
quite a work in and on itself.

What's more, after aKademy 2005's IPC BOF, we more or less came to the 
conclusion that we will not try to maintain KDE3 DCOP compatibility. The 
consequence is that KDE 3 applications will not be able to talk to KDE4 
ioslaves and klauncher nor to other KDE 4 applications. And vice-versa. 
(which poses a problem, for instance, for KDE3's K3b not being able to 
turn KDE4's mediamanager off). I'll call this a fourth option "DCOP4"

As for DCE, I'm afraid I don't know anything about it, so I will refrain 
from making any comments.

- DCOP4 is probably the easiest to implement: little to no code change, 
aside from reverting the setVersion calls that are there currently (and 
other stuff like DCOPCString)

- DCOP would require the continuation of the current efforts of 
compatibility (setVersion, etc.) and also of testing to make sure we did 
achieve compatibility

- DBUS would make us "look good" from the interoperability point of view 
and will be used in KDE no matter what -- the question is not of DBUS 
support, but if KDE will use it for its own communication.

So, what should we do?

  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

3. Ac seo woruld wearð geborod, swá se Scieppend cwæð "Gewurde Unix" and 
wundor fremede and him "Unix" genemned, þæt is se rihtendgesamnung.
-------------- 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/20051223/22aac798/attachment.sig>

More information about the kde-core-devel mailing list