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

List:       kde-core-devel
Subject:    Re: RFC: DBUS & KDE 4
From:       Waldo Bastian <bastian () kde ! org>
Date:       2004-09-29 16:57:27
Message-ID: 200409291907.09928.bastian () kde ! org
[Download RAW message or body]


On Wednesday 29 September 2004 17:43, Lubos Lunak wrote:
> On Wednesday 29 of September 2004 16:51, Waldo Bastian wrote:
> > 2) Provide DBUS support, deprecate DCOP, convert at runtime all DCOP IPC
> > to DBUS to provide 100% backwards compatibility.
> > 2) This sounds like the perfect solution, but is it feasible? It seems to
> > me that conversion of the call arguments may be impossible in cases where
> > the argument types are application defined. Due to the way DCOP works, it
> > is only possible by the receiving and sending applications in such case
> > to separate the different arguments. As such, such calls will always look
> > different from a native DBUS call with the same arguments. Is that a
> > problem? In which situations would that cause compatibility issues? Can
> > those be solved in another way?
>
>  DBUS seems to have a CUSTOM data type. Wouldn't it be sufficient to dump
> the QDataStream-created data used by DCOP as one binary object into the
> custom data type, or read it back using QDataStream? The apps shouldn't see
> any difference.

Well, yes, that's a solution for doing DCOP -> DBUS -> DCOP calls, which 
should solve a lot of compatibility issues already.

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. 

Cheers,
Waldo
-- 
bastian@kde.org  |  Wanted: Talented KDE developer  |  bastian@suse.com
  http://www.suse.de/de/company/suse/jobs/suse_pbu/developer_kde.html

[Attachment #3 (application/pgp-signature)]

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