D-BUS interfaces and whatnot (Re: KDE/kdebase/konqueror/settings/performance)

[Kevin Krammer]

On Wednesday 07 June 2006 17:54, Richard Dale wrote:
> On Wednesday 07 June 2006 16:46, Kevin Krammer wrote:
> > On Wednesday 07 June 2006 17:27, Richard Dale wrote:
> > > On Wednesday 07 June 2006 15:57, Lubos Lunak wrote:
> > > > PS: I'd also appreciate if somebody could point me to some doc
> > > > explaining what the three arguments to QDBusInterfacePtr actually
> > > > are. I'm afraid I still don't quite get it even after reading the FAQ
> > > > entry. Especially what the interface is actually supposed to be good
> > > > for is completely beyond me.
> > >
> > > Yes, and why do some of the things have slashes and others don't? For
> > > example:
> > >
> > >          dbus-send --dest=’org.freedesktop.ExampleName            \
> > >                    /org/freedesktop/sample/object/name              \
> > >                    org.freedesktop.ExampleInterface.ExampleMethod   \
> > >                    int32:47 string:’hello world’ double:65.32
> >
> > The part with the slashes is an object path, an address on how to locate
> > the object in the target process.
> > I have a little bit of overview information about this in my binding
> > backport's API dox (1)
>
> Well I've had a look and I still don't grok the difference between object
> paths and interface names, or why some have scope delimiters of '.', and
> others '/'.

The names, interface names and service names, are like fully qualified Java 
class names, allowing to have namespaces for organisations/vendors, etc

The object path is, as its name hints, similar to a path in a file system, it 
addresses a service object, which can have any number of interfaces.
As a special exception "/" is also addressing an object (root object) which is 
intended to be used for starting introspection on unknown services.

> > > I don't personally think the above is an example of a user friendly
> > > scripting call compared with the dcop command line utility. Is it
> > > possible to come up with a simpler equivalent to dbus-send for normal
> > > humans?
> >
> > We could have a kdedbus command that takes input in a more similar
> > convention to dcop
>
> Yes, I think for scripting we can assume 47 is an int, 'hello world' is a
> string and 65.32 is a float. But if these three long interface names are
> needed for each method invocation how can we get rid of them. If they
> aren't needed why are they there in the first place?

They are needed to address the service, the object within the service and the 
method to call.
However I guess we could have a tool specifically for KDE usage, which could 
prepend KDE specific prefixes automatically.

For example assume that all KDE programs will register a name like their DCOP 
name, within the org.kde. Namespace, e.g.
org.kde.KWin

There is no need to have deep object paths if the D-BUS interface is simple, 
however it might be nice to reflect the internal hierachie unto D-BUS, for 
example instead of having

konqueror-mainwindow#1
konqueror-mainwindow#2
html-widget1
html-widget2
html-widget3

it could be

/GUI/mainwindow1/html-widget1
/GUI/mainwindow1/html-widget3
/GUI/mainwindow2/html-widget2

indicating that html-widget1 and html-widget3 are children of mainwindow1

Since D-BUS is currently mainly used for communication with (system) services, 
there is no "good practice" yet, we can come up with good guidelines as we 
see fit, unrestricted by legacy schemes.

Cheers,
Kevin

-- 
Kevin Krammer <kevin.krammer at gmx.at>
Qt/KDE Developer, Debian User
Moderator: www.mrunix.de (German), www.qtcentre.org
-------------- 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/20060607/d9ba0e85/attachment.sig>