Re: How to unsubscribe?

See the "unsubscribe from this list" link at
https://lists.w3.org/Archives/Public/public-web-bluetooth/.

On Thu, Mar 31, 2016 at 4:46 PM, Amol P <electronicsguy123@gmail.com> wrote:

> Hello,
>    How do I unsubscribe from this mailing list? I did try sending an email
> with the subject "unsubscribe" but it bounces back with an error.
>
> On Thu, Mar 31, 2016 at 7:41 PM, Jeffrey Yasskin <jyasskin@google.com>
> wrote:
>
>> I think we're going to want to treat things as-if-bonded with 1 queued
>> notification, in the long run, but so far the folks writing sample apps are
>> asking for as-if-non-bonded, and that's simpler for Chrome to implement, so
>> let's go with that for now, until we start getting complaints.
>>
>> I've filed https://github.com/WebBluetoothCG/web-bluetooth/issues/226 so
>> I remember to spec this.
>>
>>
>> On Thu, Mar 31, 2016 at 7:47 AM, François Beaufort 🇫🇷 <
>> fbeaufort@google.com> wrote:
>>
>>> What is the status on this?
>>>
>>> On Fri, Mar 18, 2016 at 8:18 PM Jeffrey Yasskin <jyasskin@google.com>
>>> wrote:
>>>
>>>> On Fri, Mar 18, 2016 at 7:57 AM, Von Dentz, Luiz
>>>> <luiz.von.dentz@intel.com> wrote:
>>>> > Hi Jeffrey,
>>>> >
>>>> > On Thu, Mar 17, 2016 at 11:00 PM, Jeffrey Yasskin <
>>>> jyasskin@google.com> wrote:
>>>> >> 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.
>>>> >
>>>> > Well if that would be the case 'servicechanged' cannot be used for
>>>> > detecting new services since it appears to ignore any change outside
>>>> > the known range.
>>>>
>>>> In the design I've got so far, to detect a service you expect to be
>>>> added, you'd getPrimaryService('the-service'), catch the rejection if
>>>> it's not there, and then watch for 'servicechanged' to tell you it's
>>>> been added. Skipping the getPrimaryService() call could indeed cause
>>>> the browser to skip the 'servicechanged' event because of the rules in
>>>>
>>>> https://webbluetoothcg.github.io/web-bluetooth/#only-notify-for-requested-services
>>>> .
>>>> Those are there so the browser doesn't have to do a full discovery on
>>>> connect().
>>>>
>>>> >> 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();
>>>> >
>>>> > This seems to ignore that fact that the changes can happens while
>>>> > connected where the following events would be exactly the same.
>>>>
>>>> This example happens to show the change occurring while disconnected,
>>>> in order to highlight the difference from the as-if-non-bonded case.
>>>> If the change happens while the device is connected and after the
>>>> service has been retrieved during the current connection, I think the
>>>> bonded and non-bonded options act the same. Have I missed something?
>>>>
>>>> >>   // '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?
>>>> >
>>>> > The main concept difference appears to be persistent cache vs
>>>> > temporary cache, the miss chance is slightly bigger on the former but
>>>> > handling is almost the same either way.
>>>>
>>>> I don't really follow, sorry. IIUC, the persistent/as-if-bonded option
>>>> guarantees sites don't miss a single notification sent right after the
>>>> connection is established, and allows sites to write less code, but
>>>> requires more code from the browser. The temporary/as-if-non-bonded
>>>> option allows missed notifications, but allows a simpler browser
>>>> implementation.
>>>>
>>>> > Btw, the persistent cache can
>>>> > be used to check the services matches during the connection phase
>>>> > which further reduces the chance of cache miss.
>>>>
>>>> I still think the persistent-but-non-bonded cache can fail to notice
>>>> added and removed characteristics within an existing service whose
>>>> range doesn't change. We don't need that to change in Bluez to
>>>> implement Web Bluetooth, since we can just blame any resulting bugs on
>>>> the user's platform, but I don't want to bake it into the web API.
>>>>
>>>> Jeffrey
>>>>
>>>> >> 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
>>>> <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.
>>>> >>>
>>>> >>
>>>>
>>>>
>>
>