Re: Conclusions from the constraints spec review

On Fri, Feb 7, 2014 at 11:14 PM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

>  On 2/6/14 6:49 PM, Robert O'Callahan wrote:
>
> On Fri, Feb 7, 2014 at 10:56 AM, Harald Alvestrand <harald@alvestrand.no>wrote:
>
>> The trigger for breaking out the Constrainable interface was a request
>> from Jim (editor of MediaStreamRecorder) to have an interface he could
>> reuse, rather than having to respecify constraints from scratch if he
>> wanted to reuse the pattern.
>> We believe the breaking out makes the interface reusable, as requested,
>> and also makes the specification clearer and easier to read. Both are
>> wins.
>>
>
>  You have focused on the benefits to specifiers, who are near the bottom
> of the "priority of constituencies":
>  http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
>  Using Constrainable for MediaRecorder places burdens on implementors
> (e.g. having to implement mandatory constraints and applyConstraints() for
> MediaRecorder, when no case has been made for them being valuable in their
> own right). It also places burdens on authors for the reasons I raised
> previously. And as a reader of the MediaRecorder specification, I do not
> find that having to refer to the separate Constrainable spec and IANA
> registry --- and wade through the parts irrelevant to MediaRecorder ---
> makes it easier to read.
>
>
> I agree 100% - I hate to rain on anyone's parade, but I actually thought
> gUM was easier to read before the conversion, when Settings were camera
> settings, Capabilities were capabilities of the camera, and everything was
> spelled out in the spec. Generalizing a pattern for just one use-case does
> NOT make it easier to read IMHO. It just introduces mental indirection and
> a lot of fuzzy abstract language for no reason. Webidl definitions
> literally vanished in favor of abstract prose that's looking more and more
> like legalese. That is not an improvement in clarity.
>
> Constrainable was designed around gUM, and it has not been proven to have
> general application. Quite the contrary, we keep finding evidence it is
> specific to gUM.
>
> Evidence:
> - Mandatory constraints don't make sense when there's no permission prompt.
> - applyConstraints() pattern is only necessary when sharing resources.
> - No other applications.
>
> To repeat: Constrainable is only warranted when you're sharing resources
> behind a permission prompt. Sound general?
>

For the record, I don't believe agree with these statements.

There are plenty of reasons why one would wish to have mandatory API
points, not just for things behind a permissions promot.

-Ekr