Hi Elvis,
On Mon, Feb 21, 2011 at 7:39 PM, Elvis PfÃtzenreuter <epx@xxxxxxxxxxx> wrote:
>
> On 21 Feb 2011, at 16:14 , Claudio Takahasi wrote:
>
>> Hi,
>>
>>
>> On Wed, Feb 16, 2011 at 6:13 PM, Elvis PfÃtzenreuter <epx@xxxxxxxxxxx> wrote:
>>> This patch proposes extensions to Attribute API, giving access to all
>>> characteristic descriptors (beyond 'Description' and 'Format').
>>> ---
>>> Âdoc/attribute-api.txt | Â 28 ++++++++++++++++++++++++++++
>>> Â1 files changed, 28 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
>>> index 23808e6..5ee189e 100644
>>> --- a/doc/attribute-api.txt
>>> +++ b/doc/attribute-api.txt
>>> @@ -104,6 +104,14 @@ Methods      Âdict GetProperties()
>>>
>>> Â Â Â Â Â Â Â Â Â Â Â ÂPossible Errors: org.bluez.Error.InvalidArguments
>>>
>>> + Â Â Â Â Â Â Â void SetDescriptorValue(object descriptor, array{byte} value)
>>> +
>>> + Â Â Â Â Â Â Â Â Â Â Â Sets descriptor value, provided that it is writable.
>>> +
>>> + Â Â Â Â Â Â Â Â Â Â Â Possible Errors: org.bluez.Error.InvalidArguments
>>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â org.bluez.Error.NotAuthorized
>>> +
>>> +
>>> ÂProperties   string UUID [readonly]
>>>
>>> Â Â Â Â Â Â Â Â Â Â Â ÂUUID128 of this characteristic.
>>> @@ -143,6 +151,26 @@ Properties     string UUID [readonly]
>>> Â Â Â Â Â Â Â Â Â Â Â ÂFriendly representation of the Characteristic Value
>>> Â Â Â Â Â Â Â Â Â Â Â Âbased on the format attribute.
>>>
>>> + Â Â Â Â Â Â Â dict Descriptors [readonly]
>>> +
>>> + Â Â Â Â Â Â Â Â Â Â Â List of descriptors for this characteristic.
>>> +
>>> + Â Â Â Â Â Â Â Â Â Â Â This list contains only the descriptors not already
>>> + Â Â Â Â Â Â Â Â Â Â Â covered by other properties (v.g. Description, Format).
>>> +
>>> + Â Â Â Â Â Â Â Â Â Â Â Each descriptor is mapped to an unique object path,
>>> + Â Â Â Â Â Â Â Â Â Â Â which is the key for the dict.
>>> +
>>> + Â Â Â Â Â Â Â Â Â Â Â Each dict value is, in turn, a dict with at least
>>> + Â Â Â Â Â Â Â Â Â Â Â the following keys:
>>> +
>>> + Â Â Â Â Â Â Â Â Â Â Â {
>>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "UUID": string (descriptor UUID - mandatory),
>>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "Value": array of bytes (raw descriptor value -
>>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âoptional, shows up when value can be
>>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âfetched)
>>> + Â Â Â Â Â Â Â Â Â Â Â }
>>> +
>>>
>>> ÂCharacteristic Watcher hierarchy
>>> Â===============================
>>> --
>>> 1.7.1
>>>
>>> --
>>> 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
>>>
>>
>> In my opinion is not a good approach to allow applications(D-Bus
>> clients) to change a behavior/value of the same characteristic
>> descriptor. bluetoothd could manage automatically writing the client
>> characteristic configuration and server characteristic configuration
>> based on the registered watchers and supported client profiles.
>
> I'm not sure I follow, but let's break it down:
>
> 1) Note that this API is not just for client (and server) characteristic configuration descriptors. It is good for any kind of descriptor (like Valid Range, that client is supposed to be able to read, and set the related characteristic within its limits).
The API already has SetProperty and GetProperties that could expose
the descriptors that you need.
>
> 2) Updating automatically CCC/SCC descriptors based on Watchers sounds nice. We just need to add some kind of flag to agent registering in order to tell if we want notification or indication.
This is our initial ideia, but it is not written in the stone yet. We
need to investigate a little bit more and see which/how the Profiles
are using these characteristics descriptors.
>
> 3) In terms of client profiles, the GATT API looks generic to me, not profile-specific. As there is a way to access characteristic values in a generic way, so there is a need to do the same for descriptors.
For some descriptors I agree that we need to expose through the D-Bus
API. However for others such as CCC and SCC I don't think that we need
to allow the apps to change it. If necessary we will also have a
plugin or a service specific interface, one example is Proximity
Profile. Do you have a good use case/example in health profiles using
CCC and SCC?
BR,
Claudio.
--
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
