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

Marius Bugge Monsen wrote:
>> 3. Message Filtering.  Each application receives every dbus message on
>> the org.kde bus.  Filtering takes place in each client, rather than in
>> the server.  Together with #1 above under DBus, I fear that
>> performance will suffer.  I believe Thiago has plans to do something
>> about this?
>
>I talked to Thiago about this. It is not an easy problem to solve, but
> it is on my todo-list.

Gary's premise is not exactly correct.

We receive basically two kinds of messages:
1) all messages whose destinations are me
2) all signals

I don't think it would make sense to strip out #1, especially due to the=20
loose way the object tree is generated. We can add no extra filtering=20
there.

But #2 is definitely a performance bottleneck. Any signal is sent to all=20
running KDE applications. This is only there because no one had the time=20
to write a rule adding/removing mechanism that actually works. All the=20
other necessary components are in place.

This is only a performance problem, so changing it for Qt 4.2.1 is=20
possible (no API change, no behaviour change, no BC problems, etc.).

>> 5.  Deferred Connection.  With DCOP, one could send messages  whether
>> the receiver was running or not.   With QtDBus, you can't create an
>> interface proxy until the receiving service is actually running.  If
>> it isn't running, then you have to hook serviceRegistered or
>> serviceOwnerChanged signals, watching for the target service.  This is
>> not hard to do, but it is well hidden in the documentation, and I
>> wonder how many latent bugs will occur because devs fail to think
>> about this issue?  I'd like to see QtDBus take care of this
>> automatically.  There's a similar issue for receiving signals from
>> specific services.
>
>This is also on my todo-list :)

Also note that the act of trying to create an interface object will start=20
the remote application if it was configured to do so (i.e., installing=20
a .service file in the D-BUS services' directory).

>> Given my concerns, I'm thinking we might have done better to keep both
>> DCOP and DBus.  For pure KDE applications where interoperability is
>> not a concern, DCOP could  be used.  For applications needing to
>> support interoperability (granted, much of kdelibs), DBus would be
>> used.  This would also have offered the possibility for bridging and
>> even the possibility to bridge to KDE 3.x apps.

I completely disagree here. If DCOP should be kept, it should be only to=20
communicate with KDE 3 applications.

And a brainstorming session at aKademy last year revealed that the only=20
thing that would use that is to turn the screensaver on and off.

You cannot say whether a "pure KDE application" won't become interoperable=
=20
in the future. DCOP was never intended to be used in the extent that it=20
is being used: by scripts and to extend our applications. So, judging=20
from this past experience, we cannot imagine what our applications will=20
be doing 2-3 years from now. So using DCOP is completely out of the=20
question.

>> I realize that questioning the move to DBus now will be very
>> unpopular. kdelibs is pretty committed at this point, but are we
>> making an error we'll regret too late?

We're not. If we really need one certain feature, I'm sure we can modify=20
D-BUS itself.

Now is the time: a 0.90 release is being prepared. If you have something=20
that has to change the wire format, you have to do it BEFORE 1.0.

>I appreciate you concern. There are risks associated with moving to DBus
> (as with any new technology). But, as other posts in this thread have
> pointed out, you have the opportunity to reduce this risk by
> influencing the development of both DBus and the QDBus bindings. Use
> it; suggestions, feedback, bug reports and patches are welcome!

=2D-=20
=A0 Thiago Macieira =A0- =A0thiago (AT) macieira.info - thiago (AT) kde.org
=A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:
=A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358

--nextPart7796092.nAYsRDsqbl
Content-Type: application/pgp-signature

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

iD8DBQBEuZZiM/XwBW70U1gRAlbwAJ9wnpqeTPyql9nRuCv1c1Gs2hkmBACghavU
O6rpODwhCbrsIGqczyj1YXQ=
=A9fV
-----END PGP SIGNATURE-----

--nextPart7796092.nAYsRDsqbl--