RE: Should we expose all devices as if they were bonded?

At least for development purposes it would be nice to have them unbounded (but I guess we could have a way to change the behavior in devtools when it is open)

I am not sure whether I want the notifications to be queued, at least not by default. Think about something like temperature change and heart rate measurements. 

Kenneth

> -----Original Message-----
> From: Jeffrey Yasskin [mailto:jyasskin@google.com]
> Sent: Thursday, March 17, 2016 2:22 AM
> To: public-web-bluetooth <public-web-bluetooth@w3.org>
> Subject: Should we expose all devices as if they were bonded?
> 
> Two issues came up recently where the Bluetooth spec defines different
> behavior depending on whether a device is bonded.
> 
> In https://groups.google.com/a/chromium.org/d/topic/web-

> bluetooth/PQpZAFNlvT4/discussion
> and https://github.com/thegecko/web-bluetooth-dfu/issues/12, Luiz is
> suggesting that we have Web Bluetooth remember services, characteristics,
> and descriptors across disconnection, even when there's no physical bond.
> That's similar to treating the web site as bonded to the peripheral. We'd in
> the case of no bond, we'd re-discover the known services, etc. after re-
> connecting, and send service-changed events for the ones that have
> changed. We'd also allow users to hold onto Service, etc. objects across
> disconnect/connect pairs, and continue using the objects afterward. On the
> other hand, if we treat pages as un-bonded, users would need to re-fetch
> services, etc. before using them after a disconnect/reconnect pair.
> 
> In https://github.com/WebBluetoothCG/web-bluetooth/issues/220 and
> https://bugs.chromium.org/p/chromium/issues/detail?id=589796, we have
> to decide whether users need to re-subscribe to notifications after a
> disconnection. If we treat pages as bonded, the notification state should
> persist across disconnections. If we treat pages as non-bonded, the state
> should reset to unsubscribed on disconnection. (3.G.3.3.3.3) If we keep the
> page subscribed across disconnection, users might expect us to queue
> notifications, or at least indications, and deliver them the next time the page
> is connected. Should we do the same if the page is unloaded? That kind of
> unbounded queueing seems problematic.
> 
> And, of course, beyond always treating a page as bonded or not-bonded, we
> could make the page's bonded-ness depend on the presence of a physical
> bond.
> 
> Are there other areas where treating the page as having or not-having a
> bond would cause divergent behavior?
> 
> Which behavior do you folks think makes more sense for the web API?
> 
> Jeffrey

Received on Thursday, 17 March 2016 10:39:35 UTC