--nextPart1220351.Nct0pRAlMU
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

[Don't reply if you haven't read the whole message]
[If you do not fully understand how DCOP or DBUS works, make sure to gain a=
 =20
full understanding by asking meaningful questions BEFORE voicing an=20
uninformed opinion that makes you look like a fool [2]. It will also keep y=
ou=20
off the kde-core-devel auto-reject list.]

Hi,

I would like to discuss how KDE 4 is going to support DBUS. There are a few=
=20
different possibilities here, several requirements of varying hardness and=
=20
all this is constrained by what is actually technically possible.

Technically DBUS provides roughly the same capabilities as DCOP. This is no=
t=20
suprising given that DBUS is modelled after DCOP. The main advantage is tha=
t=20
DBUS is more widely accepted outside KDE which makes it a good candidate for
a) communication between KDE applications and the underlying operating syst=
em
b) communication between KDE and non-KDE applications.

Especially a) is a good point for supporting DBUS since the Unix OS has =20
historically been rather bad in informing non-root user space about what is=
=20
going on in the system. Lately we have solutions like libfam and DNotify on=
=20
Linux that both have their own notification mechanisms. Having a widely=20
accepted single IPC mechanism for information like this in the form of DBUS=
=20
would make it easier to export information from the kernel or root-based=20
system services to non-root user space which in turn will make it easier fo=
r=20
KDE to write KDE applications that integrate better into the operating=20
system.

b) is also a point of consideration. If we want Unix/Linux to play a=20
significant role on the desktop we will need to provide Independent Softwar=
e=20
Vendors (ISVs) with a single set of standards. If we can establish DBUS as=
=20
_THE_ Unix/Linux IPC standard we can use it as part of other standards. It=
=20
will also make it easier to let non-KDE applications integrate into the KDE=
=20
desktop.=20

=46or the above reasons DBUS is very interesting technology, and there is=20
significant demand for DBUS support from KDE application developers. As suc=
h=20
there is no doubt that DBUS will be used in the near future by KDE=20
applications. Thanks to the Qt-DBUS bindings [3] that will even be easy.

The question for KDE then becomes how we are going to support DBUS in relat=
ion=20
to DCOP. The main concern here is backwards compatibility.

There are several approaches, some of them really good, some of them really=
=20
bad, some of them perfect but not feasible.

1) Provide DBUS support in addition to current DCOP support, keep the two=20
worlds separate.
2) Provide DBUS support, deprecate DCOP, convert at runtime all DCOP IPC to=
=20
DBUS to provide 100% backwards compatibility.
3) Replace DCOP with DBUS, provide no compatibility.
4) Replace DCOP with DBUS, adjust dcopidl to generate DBUS code instead of=
=20
DCOP.
5) Something better :-)

I will now discuss the various approaches. This is the part where I would l=
ike=20
to receive informed feedback on.

DISCUSSION
=3D=3D=3D=3D=3D=3D=3D

1) We also get this if we don't do anything. Applications will start to use=
=20
the Qt-DBUS bindings anyway. It's a bad situation because developers and=20
users will start to get confused about which form of IPC to use. The good=20
thing about it is that we keep full DCOP-backwards-compatibility.

2) This sounds like the perfect solution, but is it feasible? It seems to m=
e=20
that conversion of the call arguments may be impossible in cases where the=
=20
argument types are application defined. Due to the way DCOP works, it is on=
ly=20
possible by the receiving and sending applications in such case to separate=
 =20
the different arguments. As such, such calls will always look different fro=
m=20
a native DBUS call with the same arguments. Is that a problem? In which=20
situations would that cause compatibility issues? Can those be solved in=20
another way?

3) When I talked about really bad approaches I ment this one. We MUST provi=
de=20
as much backwards compatibility as possible if we want people to consider K=
DE=20
as a serious and stable platform. Every script with "dcop kdesktop=20
KScreensaverIface lock" out there that we break means making the KDE platfo=
rm=20
less attractive for both end-users and ISVs alike. It will result in a bigg=
er=20
number on every Microsoft sponsored study out there under "TCO". And the=20
really bad thing is that they would actually have a point with that.

4) This is the 95% [1] solution. I think it's easy to pull off and 95% of a=
ll=20
code would never notice the difference. The 5% will mostly be KDE 3=20
applications that run in a KDE 4 environment. But as I explained above, tha=
t=20
5% is still too much. Is there something that we can do to solve the issue=
=20
for this 5%?

5) This space has been intentionally left blank for your proposals ;-) 5) i=
s=20
the one we will actually implement ;-) It will probably be an enhanced=20
version of either 2 or 4 or both.

Cheers,
Waldo

[1] All quoted statistics are 100% [1] made up.
[2] I pity the fool.
[3] http://trolls.troll.no/~harald/dbus/
=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

--nextPart1220351.Nct0pRAlMU
Content-Type: application/pgp-signature

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

iD8DBQBBWswGN4pvrENfboIRAqTsAKCfcMcQEw3pB0mFXkfHm32rhcFOgACgj7mR
gWk1KKkmJY3+zhYkDsQHM9U=
=O1gQ
-----END PGP SIGNATURE-----

--nextPart1220351.Nct0pRAlMU--