W3C home > Mailing lists > Public > public-web-bluetooth-log@w3.org > August 2016

Re: [web-bluetooth] Add a way to include all devices in the chooser.

From: Domenic Denicola via GitHub <sysbot+gh@w3.org>
Date: Mon, 29 Aug 2016 23:01:11 +0000
To: public-web-bluetooth-log@w3.org
Message-ID: <issue_comment.created-243283535-1472511669-sysbot+gh@w3.org>
Interesting, we were just discussing MutationObservers, which have a 
similar dictionary. Per Web IDL, the `options` argument must be 
optional, even though the prose will throw if nothing is passed. (We 
make cases like this, and like MutationObservers, add a redundant 
`optional`, so we can enforce the more generally-applicable rule that 
trailing dictionaries must be optional, since most of them don't have 
these kind of "at least one must be present" rules.)

This algorithm never seems to go "in parallel" so it's unclear why a 
promise is being used here to wrap synchronous exceptions/return 
values. I guess that's a separate issue; "request Bluetooth devices" 
should go "in parallel" instead of synchronously performing all its 

Normally I'd go with flags for consistency but in this case I see you 
have to convert it to a boolean later passing a boolean directly makes
 sense. (I wish we used booleans everywhere but we don't.)

One way to handle this might be for the internal algorithm to take a 
sequence of filters or null and use null to represent all devices. You
 could state it explicitly as "To request Bluetooth devices, given 
either a sequence of BluetoothRequestDeviceFilters or null _filters_ 
(where null represents accepting all devices) and and a sequence of 
BluetoothServiceUUIDs _optionalServices_, the UA MUST run the 
following steps:". This could clean up the internals a bit.

I think the actual requestDevice algorithm is fine. I even kind of 
like the way that the boolean defaulting to false means you can assume
 it's always present, which I guess you are unsure about. But it seems
 nice to me.

GitHub Notification of comment by domenic
Please view or discuss this issue at 
 using your GitHub account
Received on Monday, 29 August 2016 23:01:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 August 2016 23:01:18 UTC