Find out object paths

Thiago Macieira thiago at
Wed Jul 2 07:00:01 PDT 2008

Marcel Holtmann wrote:
>fair enough, but it is kinda unrealistic that low-level libdbus client
>are going to support introspection. At least not in an easy way.

I'm sorry, but that's an excuse, not a reason.

The application should send a proper introspection hierarchy, regardless 
of how it's written. If it's too difficult to do so using the low-level 
libdbus-1 library, maybe you should reconsider and use something easier.

We do not recommend using libdbus-1 except for very particular cases or 
developing bindings. Anything else should use a high-level binding.

>BlueZ, obexd and ConnMan, I am using libgdbus. Avahi is sending out the
>content of a file from the filesystem (which results in no object path
>hierarchy). All the other services based on libdbus are simply not
>introspection capable.

And Avahi is doing just fine. It replies for all object paths with the 
same introspection -- including and especially /.

That means interface browsers simply see one single object: /.

That's fine.

>And this will not change since the dependency chain of GObject or Qt are
>not acceptable to a lot of low-level service daemons. Best example would
>be wpa_supplicant which simply uses D-Bus filter callbacks only.

I understand that there are applications that are simply not meant to be 
introspected. While toying with the idea of using D-Bus for KDE's KIO 
Slaves, they would turn out to not even reply, since those applications 
are so simple that they don't even have a mainloop. (Their whole purpose 
is to make use of blocking calls)

  Thiago Macieira  -  thiago (AT) - thiago (AT)
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : 

More information about the dbus mailing list