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

--nextPart2535806.MWTNZ7XgDd
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 29 September 2004 19:12, Maksim Orlovich wrote:
> > Technically DBUS provides roughly the same capabilities as DCOP. This is
> > not
>
> It also lacks quite a few capabilities, such as DCOP's deadlock avoidance
> strategies; and suffers from an inferior base protocol that does not
> provide features such as version auto-negotiation and fully modular
> authenicaton system. I can not tell whether asynchronous replies are valid
> from the spec. The sequence numbers certainly make it possible, but the
> spec doens't really provide any sort of a clear semantic, on blocking,
> ordering, etc. These sorts of things can cause awfully subtle recursion
> bugs.

Those are very valid points that need to be addressed indeed.

> > accepted single IPC mechanism for information like this in the form of
> > DBUS
> > would make it easier to export information from the kernel or root-based
> > system services to non-root user space which in turn will make it easier
> > for
> > KDE to write KDE applications that integrate better into the operating
> > system.
>
> Of course, there is no particular technical reason to use D-BUS as such a
> protocol.

Ian identified some drawbacks of DCOP and they are all either fixable or=20
non-technical. E.g. a drawback of DCOP is that it has this awkward=20
marshalling format for custom types, in particular that you don't know its=
=20
size in the stream. Ironically that is mostly a problem when switching to=20
something else.

I have heard people talking about lack of TCP support in DCOP, but that=20
limitation is a result of policy, not a technical issue in and of itself.

> > _THE_ Unix/Linux IPC standard we can use it as part of other standards.
> > It will also make it easier to let non-KDE applications integrate into
> > the KDE
> > desktop.
>
> Integrating w/DCOP is not hard either, as evidenced by having 3 separate
> implementations of the protocol that can interoperate w/each other, 2 of
> them not using Qt, and one not using libICE.

Yes, it's mostly a matter of mindshare that makes the difference.

> You could try parsing the method signature and pray that it's accurate
> (method(QString) does not -HAVE- to use a QString. That's what we get for
> not having a written spec!). Or deprecate non-DCOPRef call interface. Of
> course, there is the fun type equivalence issue in that passing 2 integers
> in DCOP marshals the same as passing a structure w/2 ints (i.e. a QPoint),
> so one could theoretically have method(QPoint) and method(int, int)
> actually dispatch to the same C++ method. (You did mean -100%-, didn't
> you?).

100% is desirable, but I don't think it will be achievable unless you just=
=20
encapsulate the whole DCOP payload in DBUS and at its destination feed it=20
back into the original DCOP demarshalling function. (I called that DCOP ove=
r=20
DBUS in another message)

> [And custom types can be packaged as an opaque object]

Well, once we encounter a custom type we don't know where it will end, and=
=20
where the next argument starts, so we can basically only package the totali=
ty=20
of arguments as an opaque object.

> Agreed, and thanks for caring about backwards compat. One -major-
> complication, though: consider KDE3 applications running under a KDE4.
> Remember, the big excuse that's used all the time to break BC when going
> KDE N =3D> KDE N + 1 is  that "people can just install old kdelibs". Well,
> KDE3 apps are gonna need the dcopserver. And they're gonna need most of
> KDE services available through DCOP, in particular kded (with the
> cookiejar, kwallet), knotify, klauncher, etc. And not having a dcopserver
> running inside KDE4 would effectively partition them off, and cause tons
> of problems. What exactly is gonna happen to my wallet file if both the
> KDE3 kded, talked to through DCOP,a nd KDE4 kded, talked to through D-BUS,
> which are -separate processes- would try to alter it?  If we want to have
> KDE3 apps running in KDE4, we -must- support DCOP.

I fully agree.

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

--nextPart2535806.MWTNZ7XgDd
Content-Type: application/pgp-signature

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

iD8DBQBBWxIIN4pvrENfboIRApmlAKCbiN745upLlnks91V05bNIWW0LBwCfTrxx
645FC3++YqJouIB065nwdYA=
=YvIO
-----END PGP SIGNATURE-----

--nextPart2535806.MWTNZ7XgDd--