Find out object paths
thiago at kde.org
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
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: /.
>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) macieira.info - thiago (AT) kde.org
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
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20080702/3a041084/attachment.pgp
More information about the dbus