[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: RFC: DBUS & KDE 4
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2004-09-29 15:25:29
Message-ID: 200409291725.29402.l.lunak () suse ! cz
[Download RAW message or body]

On Wednesday 29 of September 2004 17:07, Zack Rusin wrote:
> On Wednesday 29 September 2004 10:51, Waldo Bastian wrote:
> > 2) Provide DBUS support, deprecate DCOP, convert at runtime all DCOP
> > IPC to DBUS to provide 100% backwards compatibility.
>
> I like that one, so the steps necessary to keep 100% backwards
> compatibility:
> 1) Provide dcop binary which maps the interfaces e.g. "kdesktop
> KScreensaverIface lock" would become
> "org.kde.kdesktop.KScreensaverIface.lock" or even better
> "org.freedesktop.screensaver.lock" and emit it via D-BUS. It does the
> translation only in the case if KScreensaverIface  is not registered
> with DCOP. So by default using the dcop binary always prefers DCOP over
> DBUS interfaces (go figure).
>
> 2) Write a kded module which listens for DCOP signals and forwards them
> correctly. Might be even off by default and people who need KDE 3.x
> compatability would turn it on.
>
> Mapping "kdesktop KScreensaverIface lock" to
> "org.kde.kdesktop.KScreensaverIface.lock"  is of course trivial but
> mapping "kdesktop KScreensaverIface lock" to
> "org.freedesktop.screensaver.lock" might seem harder. But it really
> isn't. We have a very finite amount of interfaces in
> libs/base/pim/network that we'd have to map. One hash could easily
> cover our whole cvs.

 Wouldn't it be simpler if KDE4 shipped also dcopserver, which would be the 
dcopserver we have now extended to also act as a bridge to DBUS? The mapping 
would be only in one single piece, and there would be no need for new dcop 
binary or similar (what if somebody uses the old dcop binary?). This would 
make it possible to run even unmodified KDE3 apps, and I don't think it'd be 
much harder than doing the mapping elsewhere.

> I think this covers us "protocol compatability" wise. Then there's
> source compatibility. And the question is whether we'd want to have
> libdcopxxx or whatever we'd call it, that wraps DCOP interfaces and use
> D-BUS underneath. Since we're breaking BC in KDE 4.0, I'd argue that
> it's a waste of time to be even trying to do that. But it is feasible
> and not too hard.

 I'd agree with source compatibility not being necessary, especially if the 
DBUS bindings got more care and got equivalents of DCOP stuff we have now, 
i.e. dcopidl, DCOPRef etc (right now the Qt-DBUS page feels so 1999-ish) - 
porting then could be a piece of cake. Also, in fact with supporting 
unmodified KDE3 apps there would be backwards compatibility - the KDE3 
libDCOP.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
[prev in list] [next in list] [prev in thread] [next in thread]