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 01:22:41 UTC