On Tue, 2012-08-21 at 09:23 +0200, Mikel Astiz wrote:
> From: Mikel Astiz <mikel.astiz@xxxxxxxxxxxx>
>
> The client D-Bus documentation should mention that all transfer paths
> contain a prefix consisting of the path of the session they belong to.
>
> This can be conveniently used by clients to install D-Bus signal matches
> that concentrate on the relevant signals.
> ---
> doc/client-api.txt | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/doc/client-api.txt b/doc/client-api.txt
> index 839a78c..7ca65cc 100644
> --- a/doc/client-api.txt
> +++ b/doc/client-api.txt
> @@ -466,7 +466,7 @@ Transfer hierarchy
>
> Service org.bluez.obex.client
> Interface org.bluez.obex.Transfer
> -Object path [variable prefix]/{transfer0,transfer1,...}
> +Object path [variable prefix]/{session0,session1,...}/{transfer0,...}
>
> Methods dict GetProperties()
It would be even better to explicitly mention that the "[variable
prefix]" here is the same as the "[variable prefix]" in the Session.
Or perhaps change it like this?
-Object path [variable prefix]/{transfer0,transfer1,...}
+Object path [session prefix]/{transfer0,...}
Using this knowledge efficiently is not always possible, however. D-Bus
itself has a "path_namespace" filter [1], but many D-Bus bindings don't
expose it (Python [2], GIO D-Bus [3]). Therefore a client using those
bindings still has to receive all Transfer signals and do its own
filtering.
[1] http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-routing-match-rules
[2] http://dbus.freedesktop.org/doc/dbus-python/api/dbus.connection.Connection-class.html#add_signal_receiver
[3] http://developer.gnome.org/gio/stable/GDBusConnection.html#g-dbus-connection-signal-subscribe
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
