Contact emails
jyas...@chromium.org, sch...@chromium.org, anim...@google.com
Spec
https://webbluetoothcg.github.io/web-bluetooth/
We've requested a TAG review: https://github.com/w3ctag/spec-reviews/issues/139.
Summary
Allow websites to communicate with user-selected Bluetooth Low Energy peripherals over the GATT protocol.
In M56, we want to ship the implemented subset identified at https://github.com/WebBluetoothCG/web-bluetooth/blob/master/implementation-status.md#gatt-communication-api. We intend to ship using a Finch flag so we can abort if something comes up during the rest of the Origin Trial.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/topic/blink-dev/pfNeo5cFXCk/discussion
“Intent to Experiment” and results
https://groups.google.com/a/chromium.org/d/topic/blink-dev/coyvHj1u2Z8/discussion
Results at https://docs.google.com/document/d/1BctJRNczyWVht8AtVRbD7zDLJRYHFCFsb2X3w82mjD4/edit.
Web Bluetooth has a significantly higher signup rate than the other origin trials, but we haven't done enough origin trials to know how this predicts use after we ship.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
No: We do not yet support Windows or Android WebView. The Windows 10 implementation is possible using WinRT functions but isn't finished yet. WebView needs a new API to let the embedding native app control access to the Bluetooth system. We'll implement at least Windows before significantly expanding the API, but since the primary use case is for mobile users, we didn't want to wait on Windows before giving the API to Android users.
https://github.com/WebBluetoothCG/web-bluetooth/blob/master/implementation-status.md#notes describes the version constraints on Windows, Mac, Linux, and Android. The most significant constraint is that only Android M and later is supported, in order to ask for the needed permission inline instead of during a Chrome update.
Demo link
This YouTube video controlling a micro:bit demonstrates the feature well. To try yourself requires a device to connect to. See the Web Bluetooth samples, demos, and code-labs for interactive demos, and the community for a collection of recent demos that have been shared.
Debuggability
The API produces exceptions with descriptive error messages, and we're working on a chrome://bluetooth-internals page that'll expose Bluetooth logs, which help with debugging Web Bluetooth problems.
Interoperability and Compatibility Risk
We believe Web Bluetooth has a high level of interoperability risk, but also significantly moves the web forward.
Mozilla: Servo is implementing.
Edge: Under consideration / Low.
Safari: No public signals
We believe that Edge and Mozilla have prioritized other features above Bluetooth based on their perceptions of developer needs. Mozilla has also expressed some security concerns that we've responded to. We hope that shipping in Chrome will demonstrate enough developer enthusiasm to raise their prioritization, and that it will demonstrate that the feature is secure enough to ship.
There's a chance other browsers will demand API changes at a later date, which will break compatibility with our users. We think this risk is tolerable because we've already passed the API by other spec writers and have made the changes they suggested. When there were changes, it's been possible to migrate to them backward-compatibly.
OWP launch tracking bug
Entry on the feature dashboard
https://www.chromestatus.com/features/5264933985976320
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
LGTM1
LGTM2I agree the interop risk is high, but that this adds a capability which may prove (over time) to be important to the mobile web and so worth some risk. And it's clear there's a team committed to long-term investments in standardization and interoperability here.One thing that can help reduce the interop risk (make it easier for other interoperable implementations to follow) is an interop test suite. I know much of the functionality can't currently be tested is a standard automated way (we're working towards fixing this). But has anyone explored some basic API-shape tests, or some simple manual tests, or whatever else Servo folks say would help them with their implementation?
The table here is a little worrying from a platform predictability perspective. To what extent is each row in the table easily feature-detectable? Hopefully developers should never need to hard-code things based on this table, relying only on simple feature detection.
On Fri, Oct 14, 2016 at 7:00 PM, Chris Harrelson <chri...@chromium.org> wrote:
LGTM1
On Sat, Oct 15, 2016 at 7:12 AM, Rick Byers <rby...@chromium.org> wrote:LGTM2I agree the interop risk is high, but that this adds a capability which may prove (over time) to be important to the mobile web and so worth some risk. And it's clear there's a team committed to long-term investments in standardization and interoperability here.One thing that can help reduce the interop risk (make it easier for other interoperable implementations to follow) is an interop test suite. I know much of the functionality can't currently be tested is a standard automated way (we're working towards fixing this). But has anyone explored some basic API-shape tests, or some simple manual tests, or whatever else Servo folks say would help them with their implementation?I forgot to mention this: Servo is using our layout tests, and discovered WebBluetoothCG/web-bluetooth#296 using them. Clearly that's not as good as upstreamed WPT tests, which we're scheduled to work on starting after the M56 branch point, but it seems to be effective.
The table here is a little worrying from a platform predictability perspective. To what extent is each row in the table easily feature-detectable? Hopefully developers should never need to hard-code things based on this table, relying only on simple feature detection.Most things in the table are feature-detectable by checking whether the function or attribute is undefined. The ones that aren't are:
- The elements under Discovery, because they're dictionary entries. Do you have any suggestions?
- The permissions.* items reject their promise if they get an unknown permission name.
- Persistent Device IDs aren't directly detectable, but they'll come along with permissions.query().
- Stop GATT Notifications is just silent when it's not implemented. This could waste power in the remote device.
- Event bubbling isn't detectable, but if you'd want to detect it, you can just treat it as not present.
- "{start,stop}Notifications returns this" is the same
- "Invalidate objects upon disconnect" is also similar: you just treat it as implemented in order to be compatible.
- "TypeError for bad UUIDs" was a change in the type of an exception: folks probably don't need to detect it.