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

I agree that registering service changed events is the same in both cases, but having to register for these across re-connects feels unintuitive versus scanning after a re-connect.
I am assuming that discovering services again would still return the cached ones, however.

Rob

Hi Rob,

I really meant GATT notifications, even though advertise would
probably make more sense but Im not sure it is supported in a lot of
systems, certainly not Web Bluetooth. Anyway, I don't think suggesting
to use advertise will make the problem go away as devices may already
be in the market.

Btw, the statement about having to register service changed events and
possibly holding stale services is true in any case regardless if we
persist the attributes or not because the device may change them while
connected not only when it is offline.

On Thu, Mar 17, 2016 at 1:47 PM, Rob Moran <Rob.Moran@arm.com> wrote:
> Hi Luiz,
>
> I assume you are meaning devices such as eddystone beacons?
> I'm not sure if the Web Bluetooth requestDevice() function is the best interface to observe these sorts of beacons, but is more geared towards connecting and interacting with devices.
> For purely observing devices, I think another function alongside requestDevice() (observeDevices()?) may be a better approach which can maintain the cache required for these sorts of devices, is read-only and may not need the security restrictions of requestDevice().
>
> Specific scanning apps (such as the physical web app) may also be another option?
>
> ________________________________________
> From: Von Dentz, Luiz <luiz.von.dentz@intel.com>
> Sent: 17 March 2016 11:11
> To: Rob Moran
> Cc: Christiansen, Kenneth R; Jeffrey Yasskin; public-web-bluetooth
> Subject: Re: Should we expose all devices as if they were bonded?
>
> Hi Rob,
>
> There are device that advertise, notify one value and disconnect,
> which creates a race condition where the application/page may not be
> quick enough to catch the value which is then lost as the device
> disconnects immediately to save power.
>
> On Thu, Mar 17, 2016 at 1:06 PM, Rob Moran <Rob.Moran@arm.com> wrote:
>>
>> 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.
>>
>>
>
> 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.
>

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 17:12:50 UTC