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

IMO having the device appear unbonded and requiring a user to re-discover services and re-register for events, etc. after a disconnect is a cleaner and more atomic approach.
Requiring the user to register for service changed events and possibly holding stale services (as they may not exist after a reconnect) could create more edge cases and potential errors to cover.

In this scenario, I think the item to persist between connections is the security context, so that any further reconnections don't require a user action to undertake, but still honour the original service / name filters.

Cheers,

Rob
________________________________________
From: Christiansen, Kenneth R <kenneth.r.christiansen@intel.com>
Sent: 17 March 2016 10:39
To: Jeffrey Yasskin; public-web-bluetooth
Subject: 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

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Received on Thursday, 17 March 2016 11:07:04 UTC