From kde-core-devel  Wed Sep 29 20:51:19 2004
From: Thiago Macieira <thiago.macieira () kdemail ! net>
Date: Wed, 29 Sep 2004 20:51:19 +0000
To: kde-core-devel
Subject: Re: RFC: DBUS & KDE 4
Message-Id: <200409291751.20450.thiago.macieira () kdemail ! net>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=109649109823388
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart1688014.MvQtteye2F"

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

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.

This solution would allow any calls coming from DCOP and from DBUS to work,=
=20
even those using custom datatypes.

I am assuming that our non-standard types used all over (QPoint,=20
QStringList, etc.) would be mapped to a DBUS CUSTOM type and still be=20
allowed.

>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)

Sorry, I didn't understand this one.

What do you mean?

>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.

What is not being addressed here is the DBUS-to-DCOP calls.

=46or KDE4 apps, calling a "DCOP over DBUS" method would trigger DCOP=20
marshalling and route the call via DBUS to the dcopserver, which would then=
=20
relay to the destination. This will require hardcoding of the DCOP aliases=
=20
(org.kde.dcop) and making a special DBUS call.

Non-KDE4 apps will not be able to call any of the interfaces present under=
=20
org.kde.dcop.* unless they themselves use our (tentatively so-called)=20
"libkdbus" or "libdcop+dbus".

I would much rather keep the DBUS section clean and let the dcopserver do=20
the transmarshalling. Simple types and strings are easy; common custom=20
types like QStringList, QPoint, QCursor, QPixmap, QPalette, QSize would be=
=20
encoded to their DBUS equivalents -- which have to exist anyways for DCOP=20
to be replaced with DBUS.=20

The only problem would be custom datatypes (like enums), which should be=20
avoided at all costs as of now. In those cases, when transmarshalling=20
fails, dcopserver would transmit the whole QDataStream over D-BUS. At=20
compile-time, we would also detect those border cases and write DCOP=20
demarshalling code on the app.
=2D-=20
  Thiago Macieira  -  Registered Linux user #65028
   thiago (AT) macieira (DOT) info
    ICQ UIN: 1967141   PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--nextPart1688014.MvQtteye2F
Content-Type: application/pgp-signature

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

iD8DBQBBWyBIM/XwBW70U1gRAnPIAJ4vs78xuRra+SPhVmnVIUkRFN4QQwCfUvwP
FZg8GQa/7gz+40D7MYIEKCI=
=WT9v
-----END PGP SIGNATURE-----

--nextPart1688014.MvQtteye2F--