DBus/QtDBus Concerns

[Marius Bugge Monsen]

Hi Gary,

On Wednesday 12 July 2006 04:33, Gary Cramblitt wrote:
> 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.

The documentation for QDBus needs work.
Luckily there is still time to improve it (hint: send feedback and bug 
reports:))

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

>
> 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 :)

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

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!


Regards,
Marius
(wearing my QDBus maintainer hat)