From kde-core-devel  Wed Sep 29 16:57:27 2004
From: Waldo Bastian <bastian () kde ! org>
Date: Wed, 29 Sep 2004 16:57:27 +0000
To: kde-core-devel
Subject: Re: RFC: DBUS & KDE 4
Message-Id: <200409291907.09928.bastian () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=109647704712328
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart28887085.Z9dW8WtAsq"

--nextPart28887085.Z9dW8WtAsq
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 whe=
re
> > 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 lo=
ok
> > 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 s=
ee
> any difference.

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

Let me combine a few of the suggestions in a somewhat complete solution:

=46or compatibility we could generate demarshalling for both the DCOP and D=
BUS=20
calling formats (and mark new interface so that we can only generate DBUS=20
interfaces for those). Then we can have the same interfaces available in th=
e=20
DCOP and DBUS universe.

E.g. KScreensaverIface::lock() in kdesktop could get a
org.kde.kdesktop.KScreensaverIface.lock interface using DBUS calling=20
convention and
org.kde.dcop.kdesktop.KScreensaverIface.lock interface using DCOP calling=20
convention. That is the DCOP datastream encapsulated in CUSTOM, let's call=
=20
that "DCOP over DBUS"

To reduce the overhead of the generated code we could even identify cases (=
at=20
compile time) where (the incoming) calls to the=20
org.kde.dcop.kdesktop.KScreensaverIface.lock interface can be automatically=
=20
converted to calls to its org.kde.kdesktop.KScreensaverIface.lock=20
counterpart. (Must be careful with return types though)

KDE 4 applications would then be reachable with "DCOP over DBUS" and "DBUS"=
=20
and exisiting code that makes (hand coded) DCOP calls in KDE would use "DCO=
P=20
over DBUS" while dcopidl in KDE4 would generate "DBUS" calls. For KDE 3=20
compatibility we could extend the dcopserver to change DCOP calls to DBUS=20
clients into "DCOP over DBUS" calls. The dcopserver would then be an option=
al=20
server in order to obtain KDE3 compatibility.=20

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

--nextPart28887085.Z9dW8WtAsq
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQBBWuu9N4pvrENfboIRAtTIAJ40Tg3mDlF5EdCCOaiOUV5P6scTjQCeOQwo
8A2WjMfYKbjzA2vI55n19PE=
=Pdez
-----END PGP SIGNATURE-----

--nextPart28887085.Z9dW8WtAsq--