Consider removing the `value` field from Characteristics and Descriptors about web-bluetooth HOT 7 CLOSED

No, not terrible. Keep in mind though that not having a cache means that accessing a characteristic value might result in many read requests to the same characteristic if multiple web apps want to access it. For characteristics whose value is known not to change frequently, the cached value has the advantage of avoiding an actually over-the-air request (and battery drain).

So, this is something to consider. If a value has been read, I see no harm in caching it and most platform implementations already provide a cached value. So, why not just make it accessible through the API?

from web-bluetooth.

Saving redundant reads across web apps sounds maybe-useful. (But how often will multiple apps be asking for the same value at similar times?) Do applications need to know how old the cached value is in order to use this? Would it make sense to have the application specify a maximum age for a cached value in the read() call, and then we could have a uniform interface for cached and uncached data? I think I'd still be inclined to wait for V2 for that.

from web-bluetooth.

Oh no, I wouldn't go that far at all (i.e. bother with a maximum age or anything). The way most APIs do this is to just provide the most recently read or notified value. Based on the profile, if an app knows that this value won't change (or will be notified when it does change), then they can just refer to the cached value.

For example, several apps might be interested in knowing the current battery level. The battery-level characteristic has both "read" and "notify" properties, so the app can just enable notifications from the characteristic and wait for the next update, but then also set up its initial state based on the cached value instead of sending out a read request.

And you have characteristics which may contain just long strings that won't really change frequently, so a cached value would be useful there as well.

So, there is definitely value in providing the cached value and most native APIs already support it. I don't have a strong opinion on this, so I'd let others weigh in as well.

from web-bluetooth.

I'll just comment briefly as @armansito asks for others to reply on that issue, that I'm 100% aligned with his comments. We should keep cached value for the reasons he gives in his last reply.

from web-bluetooth.

'k. @ehsan or @marcoscaceres, I'm leaning toward keeping value. Speak up if you still want to kill it.

from web-bluetooth.

(will take a look in a day or two, currently triaging a week of unread email!)

from web-bluetooth.

I think what @armansito is describing is essentially correct. Apart from first read, generally these values could be cached. Keep it for now and we can see how we go.

from web-bluetooth.