Hi Chaojie, > In this weekend, I think about this API again , and there is one question for you: > In your new proposal , bluez offer two ways for application to read characteristic value, one is to get property array of value, the other is to use ReadValue method. > For applications, in which condition they use property array of value and in which condition they use ReadValue ? will it cause a confusion for user when offer two ways for user at the same time? > In this new proposal, the "Value" property simply stores the most recently cached value after the most recent read procedure or notification/indication. So, Get will simply return this cached value. If an application wants to issue a read request to the remote peripheral, then they will call ReadValue. > You said "What if the characteristic doesn't support notifications but it's value can change?" It means cached array of value cannot be trusted in the condition you said exist if this value changes happen not result from writing to the remote end device. This is why the property is optional and wouldn't exist if the value cannot be read or notified. > So in my understanding, there is no worth to read characteristic value by property array of value, the property's role is just to emit propertychanged signal when write/read/notification operation changes its value. If so, we just define a signal such as ValueUpdated to tell user value has been changed is ok. > I only added this property back after initial feedback, which seemed to suggest that having this cached property might have some value for certain profile implementations. In short, if an application is always interested in the latest, most accurate characteristic value, then yeah, they would use ReadValue and not bother with the property at all, as you said. I personally find that caching the value after a write request is a bad idea, since bluetoothd can only guess what the new value of the remote characteristic is based on the write value that it just sent. My proposal is to only set this property and emit a PropertiesChanged after a successful read request and on notifications/indications. If we use PropertiesChanged this way, then there wouldn't be a need for ValueUpdated. I agree that this might be confusing, especially for applications that didn't issue a read request. If one application performs a read, all applications will then receive a PropertiesChanged signal, yet it is not clear to them if this was due to a notification or because somebody performed a read. This is why, in my initial proposal, I removed the "Value" property entirely, since any caching needed by an application can be performed directly by them as necessary, since most apps will be interested in getting the value directly from the remote peripheral via a call to ReadValue anyway. Then we would just have a ValueUpdated (or ValueNotified) signal which would only be emitted on notifications/indications. Marcel, any thoughts on this? > So there are two API design can be used: > 1. array of value property Get/Set (This design just happen only one condition that client write the value to remote, not in which remote change its value itself spontaneously and not send notification.) > 2. ReadValue /WriteValue method and signal ValueUpdated > > However, in the conclusion, array of value property and ReadValue/WriteValue can not be coexist, otherwise that design will result in ambiguity and not make sense. > Aside from the ambiguity that I mentioned above, these CAN nicely coexist. Again, the latest proposal is to add a read-only "Value" property which represents the cached value and have ReadValue/WriteValue for the remote procedures on the peripheral. Set is not allowed in this scenario and no read semantics are bound to Get/GetAll. -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
