From kde-core-devel  Wed Sep 29 19:55:03 2004
From: Waldo Bastian <bastian () kde ! org>
Date: Wed, 29 Sep 2004 19:55:03 +0000
To: kde-core-devel
Subject: Re: RFC: DBUS & KDE 4
Message-Id: <200409292155.06922.bastian () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=109648712203167
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart3699593.vUvsuPVe8d"

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

On Wednesday 29 September 2004 19:16, Lubos Lunak wrote:
>  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?

Coming from DCOP, we may not be able to remarshall for DBUS properly if cus=
tom=20
types are involved. Whether that's really an issue is open for debate but I=
=20
think its better to have an approach that doesn't force you to drop support=
=20
for custom types.

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

--nextPart3699593.vUvsuPVe8d
Content-Type: application/pgp-signature

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

iD8DBQBBWxMaN4pvrENfboIRAqD+AKCPBEPEezubCjI2YEbFSGCsFtRrqgCfb9xf
hljS6YDgXF9X9hgkiKxPpQM=
=YE9p
-----END PGP SIGNATURE-----

--nextPart3699593.vUvsuPVe8d--