Intent to Ship: Web Bluetooth Remote GATT Characteristic Write With/Without Response

[David Lechner]

Contact emails

da...@pybricks.com, odej...@chromium.org

Explainer

This is a small update to an existing feature, so there is not a full explainer doc. Motivation/design has been discussed at https://github.com/WebBluetoothCG/web-bluetooth/issues/238.

Spec

https://webbluetoothcg.github.io/web-bluetooth/#writecharacteristicvalue

The public writeValue(value) method and the internal WriteCharacteristicValue(this: BluetoothRemoteGATTCharacteristic, value: BufferSource, response: string) have already been implemented since Chrome 56.

This request is to add new public writeValueWithResponse(value) and writeValueWithoutResponse(value) APIs.

Web Bluetooth TAG review was done in https://github.com/w3ctag/design-reviews/issues/139.

Summary

Several issues have been found with the existing writeValue(value) method.

1. It does not allow the use to specify the type of GATT characteristic write that should be used. This is particularly a problem for devices that support both write types. Writing without response is often desirable for performance reasons, however on most platforms, writing with response is used by default.

2. The selection of writing with or without response is platform-specific. Currently most platforms will prefer writing with response, but Android preferes writing without response if both types are available on the GATT characteristic.

3. On most platforms, the current implementation depends on the device correctly reporting the available GATT characteristic write types via GATT characteristic properties. If these properties are not set, the characteristic cannot be written to.

The new APIs address all of these issues while leaving the existing writeValue(value) as-is to preserve backward compatibility. The two new APIs allow the user to explicitly select writing with or without response. The new APIs also do not depend on the GATT characteristic properties being set correctly which can allow working around buggy Bluetooth devices.

Link to “Intent to Prototype” blink-dev discussion

Since this is a small-ish non-breaking change to an existing feature, we would like to skip the prototype phase and enable this new feature by default.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Windows, Mac, Chrome OS and Android are supported.

Linux is supported with the caveat that Linux requires BlueZ 5.50+ for the new APIs to work correctly (Chrome OS has recently been updated to BlueZ 5.54). Linux with older versions of BlueZ will still work but will behave as though the old writeValue(value) method was called instead of the new APIs. The entire Web Bluetooth feature set is still experimental on Linux and is not enabled by default on that platform.

WebView is not supported because it would require changes to the WebView API to support Web Bluetooth.

Risks

Interoperability and Compatibility

Overall Web Bluetooth adoption status is described at https://github.com/WebBluetoothCG/web-bluetooth/blob/master/implementation-status.md.

TL;DR; browsers that share code with chromium implement Web Bluetooth and other browsers do not implement Web Bluetooth and have not shown interest in implementing it. Therefore, the proposed changes here do not change the overall status of Web Bluetooth interoperability or compatibility.

Ergonomics

N/A

Activation

It should be fairly trivial for developers to adopt the new APIs since it merely consists of renaming writeValue to either writeValueWithResponse or writeValueWithoutResponse. If backwards compatibility with older browsers is desired, developers should check for the existence of the new methods and fall back to existing one. For example if writeValueWithResponse !== undefined, then call writeValueWithResponse else call writeValue. Web Bluetooth is not widely used at this time, so minimal outreach should be required.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

The existing tests for writeValue have been modified to test the new APIs. Tracked at https://github.com/web-platform-tests/wpt/pull/23303.

Since this feature has not been merged yet, there are no results from wpt.fyi, but they will be here: https://wpt.fyi/results/bluetooth/characteristic?label=experimental&label=master&aligned. 

Entry on the feature dashboard

https://chromestatus.com/feature/5152041850634240

[Reilly Grant]

As a process note, this is an "Intent to Prototype and Ship".

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

--
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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO%2BHe7C7pgJvEzYiBH%3Dg2ATzzgGTaX29TuqoR6GqxtWE%2BhF-w%40mail.gmail.com.

[Chris Harrelson]

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMYCU_EWQ2Az4%2BDMvFZBRoNXZLhcnb%3DYXbwHiqD0Qy9d-Q%40mail.gmail.com.

[Mike West]

LGTM1.

This performance optimization seems like a reasonable extension of functionality that already exists, and doesn't seem to pose additional risk, either from a security perspective or from a back-compat perspective.

-mike

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Daniel Bratell]

LGTM3 (interpreting the two LGTM1 as one LGTM1+LGTM2)

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.