DBus/QtDBus Concerns

[David Faure]

On Wednesday 12 July 2006 04:33, Gary Cramblitt wrote:
> 2.  IDL Documentation.
I heard that this topic was discussed on the dbus mailing-list, I guess one of us needs
to go there and push this more :)

> 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?
I'm not sure why that's a problem. Something like QDBus::sessionBus().call(msg)
doesn't make connections "bleed out into the api in confusing ways" IMHO.

> 4.  [lack of] Maturity.
... is good for us, it's what makes fixing the lack of IDL documentation, for instance, possible.

> QTDBus

> 2.  Sender Names.  If you need to know a message's sender, this is presently 
> rather painful, requiring hand-coding of adaptors. 
Not necessarily, you can also dump using an adaptor, and use ExportSlots and 
add const QDBusMessage& to your Q_SCRIPTABLE slot.

> 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.  
It's useful when checking "is this myself". This is basically the only use case I
ever found for getting the sender of the message. Anything else would be rather
hackish (method foo() doing something different depending if it's called from
program A or program B)

> 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"?
Any KApp already registers a "appname-pid" like "kate-1234"...

> 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.
We suggested this to Marius (the new QtDBus maintainer at TT) during the Trysil
meeting and he agreed and added it to his TODO list, I was told.

1. and 4. in this section are things that you need to report to TT or Marius, 

> Given my concerns, I'm thinking we might have done better to keep both DCOP 
> and DBus. 
I disagree. KDE-4.0 isn't ready yet, we have time to fix those issues.
I didn't look into anything relating to performance yet, but for the rest DBus
works pretty well already - the kde4 desktop even starts up :)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).