Re: Fifth iteration of Settings API now available

On 12/06/2012 09:36 AM, Stefan Hakansson LK wrote:
> On 12/05/2012 04:43 PM, Harald Alvestrand wrote:
>> On 12/04/2012 11:20 PM, Martin Thomson wrote:
>>> I agree with most of Stefan's comments. I particularly like the
>>> simplifications for settings.  Fewer features === better.
>>>
>>> bitRate is something that the sink (RTCPeerConnection) can communicate
>>> back to its source, or it can resize at the encoder as it sees fit
>>>
>>> On 4 December 2012 10:55, Travis Leithead
>>> <travis.leithead@microsoft.com> wrote:
>>>>> e) We would need to specify if/how the change of one setting 
>>>>> alters the
>>>>> preference order. IIUC the constraints structure, if used only with
>>>>> optional constraints, establishes an order of preference. If the 
>>>>> first
>>>>> constraint is framerate it says that maintaining framerate within the
>>>>> bounds is more important than the following constraints. What
>>>>> happens if
>>>>> you later on change one that has lower priority? Does it pop to 
>>>>> the top
>>>>> of the list?
>>>> Yes this needs to be defined. To avoid having to re-apply all the
>>>> prior constraints just to maintain relative priority, there should be
>>>> some more elegant way to in-line adjust a setting that was previously
>>>> specified using the same relative priority, or to specify that a
>>>> setting change trumps prior priority. Any suggestions for such a
>>>> mechanism or different approaches are welcome...
>>> Given that settings/constraints are an ordered set, maybe 'set' is the
>>> wrong paradigm.
>>>
>>>    whatever.insertSetting(settings [, position = 1])
>>>
>>> With this, settings are inserted ahead of any existing setting at the
>>> given position.  Mandatory settings are at position 0, so by default,
>>> a non-mandatory setting is inserted.  (sanity note: position =
>>> Math.max(0, Math.min(position, existingSettings.length)))
>>>
>>> Unless we can agree to drop non-mandatory settings, which would make
>>> this even easier to describe.
>>>
>> I think I've mentioned this before....
>>
>> if an item is able to return the last successfully applied constraint
>> set, and we set the complete constraint set rather than doing piecemeal
>> application, a JS app can apply its own desired manipulations on the
>> setting.
>>
>> ie if you want to just insert a more important framerate.
>>
>> whatever.applyConstraints(whatever.getCurrentConstraints().optional.append({framerate: 
>>
>> 120}))
>
> "append" sounds like you're adding a new constraint at the end of the 
> list; what happens if there is already a "framerate" constraint (but 
> with another value) in the set?

I think this resolves by the rules - if you have a "framerate > 30" 
earlier and append a "framerate > 120" to the end, you will end up with 
a framerate > 120 (if the camera supports it). If you have a "framerate 
< 60" and append "framerate > 120", the last one gets ignored. If you 
want to be fancy, scan the constraints list for framerate and remove the 
one you don't like.

(I forgot to include a "min" in my example, btw - I don't like setting 
specific values; specific values are a means, and constraints should 
specify the ends one wants to achieve).


>
> (That was a detail)
:-)
>
> Even if you have no code to prove it, I agree that we could solve all 
> settings by using a constraint structure in the way you indicate. 
> However, regarding API design, I think the "get" and "set" way is more 
> in line with what web authors would expect (and my preference). This 
> is mostly a matter of taste.

Yup, in both directions.
My preference is to have one and only one conceptual model (which may be 
somewhat complex), and add utilities on top of that to make manipulation 
easy. In this case, I like the idea of a single set of constraints, 
representable as a data structure, that is either applied successfully 
or not applied.


>
> I brought the "order of preference" thing up; but perhaps it is not 
> that big a thing. I think the only potential conflict would be between 
> resolution and framerate; the others are orthogonal to each other 
> (referring to the list at 
> http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v5.html#idl-def-VideoConstraints).
>
> Stefan
>
>

Received on Thursday, 6 December 2012 11:19:58 UTC