Hi Patrick,
On Wed, Aug 22, 2012 at 2:04 PM, Patrick Ohly <patrick.ohly@xxxxxxxxx> wrote:
> On Wed, 2012-08-22 at 14:39 +0300, Luiz Augusto von Dentz wrote:
>> Hi Patrick,
>>
>> On Tue, Aug 21, 2012 at 11:31 AM, Patrick Ohly <patrick.ohly@xxxxxxxxx> wrote:
>> >> 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,...}
>>
>> Hmm, I prefer the original proposal since that imo looks more clear
>> how the path is formatted, anyway the point here is that the transfers
>> are tied to sessions.
>
> But as Marcel said, "variable prefix" means "no guarantee made about its
> content, none whatsoever". Without knowing Bluez conventions, that was
> also my understand when reading the API description. Assigning some
> other meaning to "variable prefix" would break with developer
> expectations.
>
> Unless the meaning of "variable prefix" gets redefined, "[variable
> prefix]/{session0,session1,...}" still doesn't allow the developer to do
> path_namespace filtering.
>
> How about this:
>
> -Object path [variable prefix]/{transfer0,transfer1,...}
> +Object path [prefix]/{session0,session1,...}/{transfer0,...}"
> + with "prefix" as in the corresponding session
>From my point of view, this is beyond the scope of this patch. The
modification proposed here is in general consistent with the existing
documentation in the mentioned projects, and in particular with the
file being modified (see org.bluez.obex.Message).
I agree that the exact interpretation of "variable prefix" is
undocumented, but fixing that has a broad scope affecting several
projects. See for example org.bluez.Device or org.ofono.VoiceCall.
Personally, I find it relatively obvious that both variable prefixes
match. Otherwise there would be no reference to the session (or
BlueZ-adapter, oFono-modem, etc., depending on the case).
Regarding the lack of support in some bindings, I would say it's not
critical. After all, we're doing an optimization here (reduce number
of context-switches). If someone is using a limited binding, then
there's a performance penalty.
Cheers,
Mikel
--
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
