V4 comments (Re: Settings API Proposal v3 feedback summary)

On 10/03/2012 03:10 AM, Travis Leithead wrote:
> V4 is now ready. I've posted it on Mercurial for easier reading:
>
> http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v4.html
>
> Thanks! Looking forward to your continued feedback.
>
Thanks Travis!

I like the way this is moving - in particular, I like the idea of 
reducing the number of places where apps have to care what kind of 
stream or track they're handling.

Some worries persist, however:

- I really like the idea in section 3 where you model the request 
interface as "construct a constraints object and apply it". This unifies 
the constraints namespace and the namespace for requested attributes 
quite neatly.
HOWEVER - the namespaces are a bit non-overlapping, in particular the 
control of height and width, where you introduce a new enumerated 
"dimension" namespace. When items in both namespaces collide, do we 
synthesize an union, or do we declare a winner?

- It's not clear to me what happens to existing constraints placed on a 
track after a series of "request" calls and subsequent applications; are 
the constraint lists merged into an intersection? are they replaced? or 
is this device and implementation dependent?
I'm particularly thinking of usage patterns where an implementation uses 
constraints at the getUserMedia phase to get a suitable device, and then 
uses the request interface to manipulate it afterwards; is he allowed to 
set constraints outside the originally specified ones, or isn't he?
Not clear what the right answer is, but there should be only one.

- I've worried about this before and gotten some pushback, but I'm still 
worried about the wisdom of setting specific values rather than 
"acceptable ranges" - for instance, some systems will drop resolution, 
framerate or encoding complexity based on CPU temperature, to avoid 
systems shutting down mid-call under "hot" conditions. Setting specific 
values will seem to take away that freedom; setting a range of "values I 
can live with" would preserve it.

- I wonder if experimentation and flexibility could be served if we 
could generalize the interface, so that we don't have to rev the API 
every time we add a setting - the long list of settings in 
PictureAndVideoSettings could possibly be expressed as

interface MediaSetting {
     DOMString name;
     (MediaSettingsList or MediaSettingsRange) setting;
}

interface PictureAndVideoSettings {
    MediaSetting[] settings;
}

I don't know if it is wise, but I'd like to hear others' thoughts on 
such an API:

- lastly, I think that in some cases, for some constraints, it makes 
sense to offer a media settings interface on *any* media stream track, 
including remote ones. I wonder if we can generalize it to be an 
interface on MediaStream itself without hurting it?

                     Harald

Received on Thursday, 4 October 2012 13:52:06 UTC