Hi Arman, >> 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. without thinking too much about the details, I think when notification is enabled, then we just wait for the update from the remote device. If notification is not enabled, then we update the value on write. Since everything is central in bluetoothd, we should be able to make smart decisions. Regards Marcel -- 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
