DBus/QtDBus Concerns

[Gary Cramblitt]

I have some concerns about DBus and feel someone should speak up.  I fear that 
the decision to drop DCOP entirely and jump to DBus may have been premature 
and without the full implications understood.

My concerns fall into two groups -- 1) concerns about DBus itself, and 2) 
concerns about the QtDBus implementation.

DBus
-------

1.  Performance.  At least one benchmark puts DBus at 6 times slower that 
DCOP.  Now benchmarks are frequently misleading, but this does raise a risk  
flag.  Wouldn't it be a tragedy if KDE4 were released and the community's 
reaction were "Wow, looks great, but runs too darn slow."  Has anyone 
actually run some performance testing approximating the KDE environment?

http://eleceng.dit.ie/frank/rpc/CORBAGnomeDBUSPerformanceAnalysis.pdf

2.  IDL Documentation.  The DBUS IDL specification does not permit 
programmer's to document their interfaces in the xml files.   This is a 
recognized problem with at least two aspects: 1) The need to provide 
interface documentation at run time (introspection), and 2) The need to 
provide more extensive documentation for programmers.  Presently, we have to 
provide documentation separately from the IDL xml file, which is a formula 
for errors.

3.  Connections.  I don't understand the need for DBus to define connections.  
One can already send a message to an object and/or interface on a service, so 
why are connections involved?  If they were an internal implementation detail 
that doesn't affect apps, OK, but unfortunately they "bleed" out into the api 
in confusing ways.  Sometimes one is dealing with a service name, and 
sometimes with a connection name.  (This might actually be a QtDBus issue.  
I'm not sure.)

4.  Maturity.  This statement in the DBus 0.62 README says it all.

"Until 1.0 is released, feedback that requires API changes may be
incorporated into D-BUS. This may break the API, the ABI, the
protocol, or all three.

Until 1.0 is released, you have to define -DDBUS_API_SUBJECT_TO_CHANGE
just as a safety check to be sure everyone is aware of this API/ABI
policy and has the right expectations."

QtDBus
-----------

1.  Documentation.  The documentation for QtDBus is presently barely adequate 
with numerous typos and errors.  I'm sure this will improve with time, but 
using it now is a bit of an "adventure".  (I'm out of time tonight, but I 
promise to send my notes, in the hope that someone will incorporate them into 
the docs please.  I'd attach patches, but in many cases, I don't know what 
the correct information is.)  One of the things that makes it confusing is 
that every client is a service, so sometimes it isn't very clear when the 
documentation talks about a "service", whether it is talking about the sender 
or the receiver.  Also, I mentioned the confusion between service names and 
connection names.

2.  Sender Names.  If you need to know a message's sender, this is presently 
rather painful, requiring hand-coding of adaptors.  Knowing who you are 
talking to is fundamental.  What's the first thing you want to know when you 
answer the phone and say "Hello"?   Furthermore, the name is a connection 
name that isn't very useful.  DBus permits clients to request a connection 
name, so why don't we take advantage of this and make the names more 
friendly, like ":kate-1234" instead of ":1.15"?

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?

4. Introspection.  Before all the debugs were turned off, I noticed that every 
msg my app sent seemed to generate multiple introspections.  Again, 
performance concern.  Perhaps this has been fixed by now?  Or maybe I'm doing 
something wrong?   It seems to me something is wrong if the implementation 
has to request the entire interface specification in order to make one method 
call.  Under DCOP, the marshalling was done according the type information 
provided by the caller.  (If this was wrong, the message failed.)  Under 
QtDBus, the marshalling is done according to the receiver's interface 
definition, which leads to all the excess introspection.

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.

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 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?

Finally, all of the above are *concerns*.  I am *not* saying that the move to 
DBus *is* a mistake; just that it *might* be a mistake, possibly a costly 
one.

-- 
Gary Cramblitt (aka PhantomsDad)
KDE Text-to-Speech Maintainer
http://accessibility.kde.org/developer/kttsd/index.php