- From: Jeffrey Yasskin <jyasskin@google.com>
- Date: Fri, 18 Mar 2016 08:39:51 -0700
- To: Rob Moran <Rob.Moran@arm.com>
- Cc: "Von Dentz, Luiz" <luiz.von.dentz@intel.com>, public-web-bluetooth <public-web-bluetooth@w3.org>, "Christiansen, Kenneth R" <kenneth.r.christiansen@intel.com>
On Fri, Mar 18, 2016 at 6:00 AM, Rob Moran <Rob.Moran@arm.com> wrote: > > Thanks Jeffrey, your scenarios make sense. > > > The non-bonded flow reflects my description and is what I'd advocate for In > this case, the answer to your question should probably be: > > > service !== service2; // true > > > If we were to go with the bonded scenario, however, I'd also expect the > characteristics and descriptors to persist across connections, negating the > need for the second: > > > characteristic === await service.getCharacteristic('uuid2'); Right. > This approach would also require further characteristicchanged events, too. If we take Vincent's suggestion from https://github.com/WebBluetoothCG/web-bluetooth/issues/53, I think we'd have a single 'serviceschanged' event that includes information about characteristics that change on their own too. We could call it 'attributeschanged' if "services" looks too tied to just services. > Kind regards, > > > Rob > > > ________________________________ > From: Jeffrey Yasskin <jyasskin@google.com> > Sent: 17 March 2016 21:00 > To: Rob Moran > Cc: Von Dentz, Luiz; public-web-bluetooth; Christiansen, Kenneth R > > Subject: Re: Should we expose all devices as if they were bonded? > > On Thu, Mar 17, 2016 at 10:12 AM, Rob Moran <Rob.Moran@arm.com> wrote: >> >> 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. > > > If we treat devices as not-bonded, I think we get: > > await device.gatt.connect(); > // Depends on https://github.com/WebBluetoothCG/web-bluetooth/issues/53: > device.addEventListener('servicechanged', change => console.log(change)); > let service = await device.gatt.getPrimaryService('uuid'); > let characteristic = await service.getCharacteristic('uuid2'); > device.gatt.disconnect(); > await device.gatt.connect(); > await service.getCharacteristic('uuid2') // Throws InvalidStateError: > service no longer exists? > let service2 = await device.gatt.getPrimaryService('uuid'); // Waits until > discovery process finishes. > service ?== service2; // ??? > device.gatt.disconnect(); > // 'uuid' service removed, replaced with 'uuid3' service. > await device.gatt.connect(); > await service.getCharacteristic('uuid2') // Throws InvalidStateError: > service no longer exists? > let service3 = await device.gatt.getPrimaryService('uuid'); // > NotFoundError. > let service4 = await device.gatt.getPrimaryService('uuid3'); > service4 !== service2; > > I think we wouldn't get any 'servicechanged' events in this scenario, since > the changes happen when no services are known. > > > If we treat devices as bonded, I think we get the following flow instead: > > await device.gatt.connect(); > // Depends on https://github.com/WebBluetoothCG/web-bluetooth/issues/53: > device.addEventListener('servicechanged', change => console.log); > let service = await device.gatt.getPrimaryService('uuid'); > let characteristic = await service.getCharacteristic('uuid2'); > let value = await characteristic.readValue(); > device.gatt.disconnect(); > await device.gatt.connect(); > characteristic === await service.getCharacteristic('uuid2'); > service === await device.gatt.getPrimaryService('uuid'); > await device.gatt.getPrimaryService('uuid3'); // NotFoundError > device.gatt.disconnect(); > // 'uuid' service removed, replaced with 'uuid3' service. > await device.gatt.connect(); > // 'servicechanged' fired some time after this. Let's say it doesn't > arrive for a while. > service === await device.gatt.getPrimaryService('uuid'); // Cached. > characteristic === await service.getCharacteristic('uuid2'); // Cached. > let value = await characteristic.readValue(); // InvalidStateError? What > GATT error does this cause? > await device.gatt.getPrimaryService('uuid3'); // Cached NotFoundError. > // Say 'servicechanged' arrives now. Listener logs it to console. > let service2 = await device.gatt.getPrimaryService('uuid3'); // Succeeds. > let service3 = await device.gatt.getPrimaryService('uuid'); // > NotFoundError. > > > Does that all make sense? Does it convince anyone to prefer as-if-bonded or > as-if-not-bonded? > > Jeffrey > >> >> 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. >> > > 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 Friday, 18 March 2016 15:40:40 UTC