- 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
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 work. 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 https://github.com/WebBluetoothCG/web-bluetooth/pull/278#issuecomment-243283535 using your GitHub account
Received on Monday, 29 August 2016 23:01:17 UTC