Intent to Prototype & Ship: toJSON() for MediaSettingsRange

[François Beaufort]

Contact emails

fbea...@chromium.org, rei...@chromium.org

Spec

Specification: https://w3c.github.io/mediacapture-image/#dom-mediasettingsrange-tojson

PR: https://github.com/w3c/mediacapture-image/pull/234

Summary

Allow web developers to aggregate and easily log media settings ranges (max, min, step) in JSON.

Motivation

Adding toJSON() to MediaSettingsRange will improve developer ergonomics by allowing web developers to easily log and aggregate exposureCompensation, exposureTime, colorTemperature, iso, brightness, contrast, saturation, sharpness, focusDistance, pan, tilt, and zoom.

For info, MediaDeviceInfo returned by navigator.mediaDevices.enumerateDevices() already has a toJSON() method.

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

The feature will be supported on all platforms.

Interoperability: None
Gecko: No Signal

Webkit: No Signal

Compatibility: None

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

Web platform tests will be updated and available at https://wpt.fyi/results/mediacapture-image.

Feature dashboard

https://www.chromestatus.com/feature/5677894124699648

[Mike West]

Adding a default `toJSON()` implementation seems like a quite small and reasonable thing to do, without substantial interop risk.

That said, I do wonder whether both `MediaSettingsRange` and `MediaDeviceInfo` could be `dictionary` objects rather than `interface`s. That would, I think, allow `JSON.stringify()` to operate on those objects without doing any additional work, as all the types seem to be JSON types.

-mike

[Domenic Denicola]

From: Mike West <mk...@chromium.org>

> That said, I do wonder whether both `MediaSettingsRange` and `MediaDeviceInfo` could be `dictionary` objects rather than `interface`s. That would, I think, allow `JSON.stringify()` to operate on those objects without doing any additional work, as all the types seem to be JSON types.

+1. These appear to be simple data holders, and not classes/interfaces with data and behavior and inheritance.

However, the changes needed would be a bit more extensive, as they are used by other parts of the IDL that does not work with dictionaries. In particular, PhotoCapabilities should become a dictionary too (which would also allow use of sequence<> instead of FrozenArray).

And MediaDeviceInfo has a subclass, InputDeviceInfo, which does have a method, getCapabilities(). It's unclear whether that method really needs to be a method, instead of potentially being another dictionary property, but perhaps it's desired to only construct the relevant MediaTrackCapabilities upon request (instead of eagerly, as would be required if getCapabilities() became a `capabilities` attribute).

So, I'd advise making the change for MediaSettingsRange and PhotoCapabilities. MediaDeviceInfo might not be worth the churn.

[François Beaufort]

Thanks for the valuable feedback folks!
I've filed a PR spec at https://github.com/w3c/mediacapture-image/pull/238 to change MediaSettingsRange & PhotoCapabilities interfaces to dictionaries as suggested.
I'll update this thread when it lands.

[Francois Beaufort]

[François Beaufort]

This intent has been replaced by "Intent to Prototype & Ship: Change MediaSettingsRange & PhotoCapabilities interfaces to dictionaries"

See https://groups.google.com/a/chromium.org/g/blink-dev/c/QI8BS5bL5CQ