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

Hi Jeffrey,


How exactly would one queue if the state should reset to unsubscribed?
Or do you mean that any and all notification/indication shall be
queued and replayed to the application/page once it subscribe again?
If I would read this for the stack point of view it means it shall
remember the subscriptions so that the UA can queue them, which sounds
the same as been 'bounded', we actually use terms like
temporary/persistent device in BlueZ since 'Bounded' refer to
link-keys being stored which is different than what we are trying to
accomplished.

In case someone is wondering how persistent/temporary devices works in
BlueZ, any action that triggers a connection to a certain device would
make the device persistent including its attribute cache. This is
actually not only useful for not losing early notifications but also
to automatically reconnect using passive scanning, though the later
actually requires the application to register an agent with
RegisterProfile:
https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/gatt-api.txt

On Thu, Mar 17, 2016 at 12:39 PM, Christiansen, Kenneth R
<kenneth.r.christiansen@intel.com> wrote:
> 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 11:08:13 UTC