RFC: DBUS & KDE 4
l.lunak at suse.cz
Wed Sep 29 18:16:02 BST 2004
On Wednesday 29 of September 2004 19:07, Waldo Bastian wrote:
> Let me combine a few of the suggestions in a somewhat complete solution:
> For compatibility we could generate demarshalling for both the DCOP and
> DBUS calling formats (and mark new interface so that we can only generate
> DBUS interfaces for those). Then we can have the same interfaces available
> in the DCOP and DBUS universe.
> E.g. KScreensaverIface::lock() in kdesktop could get a
> org.kde.kdesktop.KScreensaverIface.lock interface using DBUS calling
> convention and
> org.kde.dcop.kdesktop.KScreensaverIface.lock interface using DCOP calling
> convention. That is the DCOP datastream encapsulated in CUSTOM, let's call
> that "DCOP over DBUS"
> To reduce the overhead of the generated code we could even identify cases
> (at compile time) where (the incoming) calls to the
> org.kde.dcop.kdesktop.KScreensaverIface.lock interface can be automatically
> converted to calls to its org.kde.kdesktop.KScreensaverIface.lock
> counterpart. (Must be careful with return types though)
> KDE 4 applications would then be reachable with "DCOP over DBUS" and "DBUS"
> and exisiting code that makes (hand coded) DCOP calls in KDE would use
> "DCOP over DBUS" while dcopidl in KDE4 would generate "DBUS" calls. For KDE
> 3 compatibility we could extend the dcopserver to change DCOP calls to DBUS
> clients into "DCOP over DBUS" calls. The dcopserver would then be an
> optional server in order to obtain KDE3 compatibility.
Am I getting it right that you'd want to add the backwards compatibility
support to the DBUS code in KDE4? Wouldn't it be better to keep KDE4 nice and
clean and make it DBUS-only? The ugliness of backwards compatibility could be
kept separately in dcopserver.
The mapping could be solved by dcopserver registering in the DBUS space as
all the DCOP clients (with names adjusted for DBUS). Requests from DBUS would
be re-marshalled for DCOP by dcopserver and sent to the right DCOP client.
Requests from DCOP clients would be sent normally to other DCOP clients, and
would be re-marshalled for DBUS and sent there. Indeed, that'd be a bit
slower, but I don't think we should prefer old code to new code. Moreover,
even your solution would need at least part of this to be done in dcopserver,
so why not do it there completely?
SuSE CR, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
More information about the kde-core-devel