Hi Vinicius,
On Thu, Mar 10, 2016 at 8:04 PM, Vinicius Costa Gomes
<vinicius.gomes@xxxxxxxxx> wrote:
> Hi Luiz,
>
> Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> writes:
>
>> From: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx>
>>
>> GattServices is not really doing was it was meant to do which was to
>> track progress of service discovery since it only worked for the very
>> first time a device is connected but since we no longer remove the
>> attributes an application would have the false impression the service are
>> all resolved by the time it reconnects when in fact the service may have
>> changed.
>>
>> Futhermore object tracking like it is doing has been obsolete by
>> ObjectManager so this propose to replace the service discovery tracking
>> with a boolean property which works both with SDP as well as GATT
>> discovery.
>> ---
>> doc/device-api.txt | 9 +++------
>> src/device.c | 58 +++++++++++-------------------------------------------
>> 2 files changed, 14 insertions(+), 53 deletions(-)
>>
>> diff --git a/doc/device-api.txt b/doc/device-api.txt
>> index a8076a2..9e58664 100644
>> --- a/doc/device-api.txt
>> +++ b/doc/device-api.txt
>> @@ -212,10 +212,7 @@ Properties string Address [readonly]
>> Service advertisement data. Keys are the UUIDs in
>> string format followed by its byte array value.
>>
>> - array{object} GattServices [readonly, optional]
>> + bool Discovering [readonly, optional, experimental]
>>
>> - List of GATT service object paths. Each referenced
>> - object exports the org.bluez.GattService1 interface and
>> - represents a remote GATT service. This property will be
>> - updated once all remote GATT services of this device
>> - have been discovered and exported over D-Bus.
>> + Indicate whether or not service discovery is in
>> + progress.
>
> I wonder how useful it's going to be.
>
> What I expect from a client is that it made a GetManagedObjects() call
> when it entered the bus and added listeners to the InterfacesAdded(),
> InterfacesRemoved() and PropertiesChanged() signals, I am not seeing
> what kind of value this property is adding to that kind of client.
>
> But yeah, it is better than GattServices.
I have fight this over in Web Bluetooth, but the design there is
different since it does not expect the stacks to build a cache of the
attributes so they end up with something like a GetPrimaryServices
method which would return the current list of services, but it turn
out they could be outdated if the device database has changed:
https://github.com/thegecko/web-bluetooth-dfu/issues/12#issuecomment-194973956
That said there is this problem that if an application start using the
current objects as soon as it reconnects it may get errors if they are
outdated, I still thing this is better than having to wait the
discovery to complete and not being able to do any access to
attributes before that happens, also which objects not being removed
on disconnect we can persist notifications which is something I
believe is not possible with other stacks, it is probably racy to do
in the applications because by the time you have a new connection
comes in it has to react to that to subscribe again but in the
meantime it can loose notification that had happened quickly enough.
--
Luiz Augusto von Dentz
--
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
