From kde-core-devel Wed Jul 12 09:49:45 2006 From: David Faure Date: Wed, 12 Jul 2006 09:49:45 +0000 To: kde-core-devel Subject: Re: DBus/QtDBus Concerns Message-Id: <200607121149.45828.faure () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=115269785532075 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@kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).