W3C home > Mailing lists > Public > public-media-capture@w3.org > February 2014

Re: Conclusions from the constraints spec review

From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 8 Feb 2014 08:00:00 -0800
Message-ID: <CABcZeBMA49GR5J7i8j4aujr6oU6ONu=rDdiezaKnVbRxmykNXQ@mail.gmail.com>
To: Jan-Ivar Bruaroey <jib@mozilla.com>
Cc: "Robert O'Callahan" <robert@ocallahan.org>, Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
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
Received on Saturday, 8 February 2014 16:01:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:24 UTC