KDE4's IPC

Thiago Macieira thiago at kde.org
Fri Dec 23 15:42:57 GMT 2005


Thiago Macieira wrote:
>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).

My own opinion on this matter is that we should take the extra effort and 
go all the way with DBUS.

My reasoning is as follows:
- maintaining backwards DCOP compatibility ("DCOP" in the original post) 
will probably give us a lot of headaches:
 * we cannot load KDE3 ioslaves into KDE4's kdeinit
 * we cannot load KDE3 kded modules into KDE4's kded
 * we would have to maintain the KIO-KIOSlave wire format as well as
   DCOP's (i.e., setVersion in KIO::Connection as well)
 * applications and services would be mandated to keep their current DCOP 
   public API, which was never intended to be kept in the first place
 * we have to find all uses of QDataStream in DCOP and KIO and add the 
   proper setVersion calls (can be eased with a DCOPStream helper class)

- so we end up with DCOP4, which is basically DCOP separated from KDE3's 
DCOP, but breaking backwards compatibility and fixing any shortcomings 
found along the way (the lack of versioning & handshake in the stream, 
for one thing)

- however, if we're breaking compatibility anyways, why not go all the way 
to DBUS?
 * would make us "look good" from interoperability point of view
 * would make us embrace an FD.o spec and show our support for the org
 * would ease the use of the system bus (which will be DBUS anyways), 
   which is currently used only in kded/mediamanager
 * would allow us to take the lead in DBUS development and fix its 
   shortcomings to our liking

Also, from the technical point of view, I find DBUS' wire format to be 
superior to that which we're using on DCOP. For one thing, the 
marshalling format is kept on-stream, instead of relying on each end 
knowing what they're supposed to marshall/demarshall. The drawback is 
that the format does not allow for direct one-to-one mapping of Qt and 
KDE classes.

-- 
  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/b6b103cc/attachment.sig>


More information about the kde-core-devel mailing list