Re: [RFC v1 1/1] doc/gatt-api: New API properties and methods for the GATT D-Bus API.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Marcel,


> I think one detail that has to be clear os that most likely nobody is calling Get directly. I will be available, but mostly all applications will get the value from calling GetManagedObjects.
>
> So lets say we talk about standard service like Device Information or Battery Status etc., every application gets these information in one go. This is comparing to x number of application calling ReadValue for each value individually. For values that do not change at all or change only every x days this is something that makes sense and I really want. It means that applications do not have to do anything extra for these values. They are just available and they are most likely recent or recent enough.
>

Fair enough, this was enough to sell this to me :)

> I think this depends a little bit. Most values will be return the exact same value that you write into it. That is what they are suppose to do anyway. The only exception here are control endpoints. So I would agree that for control endpoints we do not expose the Value property at all.
>

Yes, we shouldn't expose the Value property if the characteristic
properties field doesn't contain "read", "notify", or "indicate". With
respect to caching the value before a write operation, I'm still
hesitant towards making any assumptions about the value. I wouldn't
want to cache the value until after the write operation has completed
successfully (which is only possible to determine with the "write
request" and "reliable long write" procedure) and there may be some
race conditions where a characteristic might immediately change it's
value and send a notification before we had a chance to store the
write value. In this case the latest cached value would be incorrect.
I understand that this is an edge case but it's enough to raise some
concern.

Anyway, we can start out by caching the write value and if people run
into any issues in the field, we can then change the behavior in the
future.


Cheers,
Arman
--
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




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux