KDE4's IPC
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:
- DBUS
- DCE
- DCOP
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
defaults.
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