- From: Christiansen, Kenneth R <kenneth.r.christiansen@intel.com>
- Date: Thu, 17 Mar 2016 10:39:04 +0000
- To: Jeffrey Yasskin <jyasskin@google.com>, public-web-bluetooth <public-web-bluetooth@w3.org>
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