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