- From: Gordon Williams via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Jul 2020 10:40:20 +0000
- To: public-web-bluetooth-log@w3.org
+1 for AbortController on connect, but I feel that applying AbortController to everything is a *really bad* idea. IMO AbortController should be for aborting tasks which you expect to complete in most cases and only want to abort in rare cases. The signal pattern allows you to specify the ability to abort but keeps the API tidy for the majority of cases, which is great. By contrast, `startNotifications`, `watchAdvertisements`, `requestLEScan` are activities. They're not things that you ever expect to complete on their own, so you don't want to 'Abort' them. You just want an easy way to stop them. If you use AbortController then if you accidentally call `watchAdvertisements` with no signal, you're stuck. There's *no way* to stop scanning for advertisements, even if you have a reference to the device itself. Literally the only way to stop the advertisements coming in is to force the page to refresh - which feels to me like a big design problem - same applies if `stopNotifications` or `BluetoothLEScan.stop()` were removed -- GitHub Notification of comment by gfwilliams Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/439#issuecomment-662936648 using your GitHub account
Received on Thursday, 23 July 2020 10:40:21 UTC