DBus/QtDBus Concerns

[Thiago Macieira]

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 
loose way the object tree is generated. We can add no extra filtering 
there.

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

This is only a performance problem, so changing it for Qt 4.2.1 is 
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 
the remote application if it was configured to do so (i.e., installing 
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 
communicate with KDE 3 applications.

And a brainstorming session at aKademy last year revealed that the only 
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 
in the future. DCOP was never intended to be used in the extent that it 
is being used: by scripts and to extend our applications. So, judging 
from this past experience, we cannot imagine what our applications will 
be doing 2-3 years from now. So using DCOP is completely out of the 
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 
D-BUS itself.

Now is the time: a 0.90 release is being prepared. If you have something 
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!

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060716/aff434d4/attachment.sig>