Discussion of "zoom" does not consider mechanical zoom timing

[alvestrand]

With non-electronic zoom, moving from one zoom setting to another takes time (seconds).

This specification should say how this is considered.
Options include:

• The desired zoom is what's returned in getPhotoCapabilities. The camera does what it wants.
• getPhotoCapabilities returns the current zoom. The user has to poll getPhotoCapabilities until the camera's zoom is at the desired point (and keep track of what the desired point is).
• setOptions() doesn't resolve its promise until the correct zoom has been reached

Either is viable, but which one is intended has to be specified.

[yell0wd0g]

Tentatively closing this issue, please re-read and comment or reopen.

[alvestrand]

Big improvement, but not quite there.... Does the promise resolve once the value has reached its target value, or once the target value has been set and modification has started?

Either is a valid decision, but only one should be in the spec.

[alvestrand]

the note

NOTE
If the UA can successfully apply the settings, the effect may be reflected, if visible at all, in videoStreamTrack. The result of applying some of the settings may force the latter to not satisfy its constraints (e.g. the frame rate).

is not reasonable; it specifies a number of dimensions in which the result of the call can vary, without giving normative guidance to the implementor on what should happen.

I'm particularly worried about the "may cause the track to be overconstrained" language - this will cause the track to go black for all other purposes.

Moving setOptions to be a parameter on takePhoto would resolve this issue, since takePhoto is already specified to be able to suspend the track and restore it to its original settings after the photo has been taken.

[yell0wd0g]

#124 has a discussion that should cover solving this issue.