RE: Conclusions from the constraints spec review

Having constrainable in a separate doc was never really the goal in my opinion--just having it defined as a separate reusable interface was all that was needed. Putting aside the utility of the interface itself, if the issue can be solved by re-integrating it into one or the other of the other specs, then we could agree to just do that.

However, it sounds like you are expressing deeper concerns about the utility (and usability) of the interface. I believe it certainly fills a need for controlling unpredictable and varied media sources in the getUserMedia spec, and I think it can also be useful in media recording, but I'm open to entertaining alternate proposals as well.

________________________________________
From: Harald Alvestrand <harald@alvestrand.no>
Sent: Thursday, February 6, 2014 8:31 PM
To: Cullen Jennings; Robert O'Callahan
Cc: public-media-capture@w3.org
Subject: Re: Conclusions from the constraints spec review

On 02/07/2014 12:55 AM, Cullen Jennings wrote:
> On Feb 6, 2014, at 4:49 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
>
>> On Fri, Feb 7, 2014 at 10:56 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
>> After reading through the messages sent on this topic, and after
>> consulting with the editors, the chairs have reached the following
>> conclusions and action plans:
>>
>> - We will keep the Constrainable interface, with the current structure.
>> - We will make one registry of constraints, common across all usages.
>> - We will change the type of ConstraintSet to be a typedef of Object.
>>
>> Details on each of these:
>>
>> 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 would like to ask the W3C TAG to consider these issues and offer their opinion. Do you have any objection to that? We did this for some contentious issues in Web Audio and it worked well.
>>
>> Rob
>> --
> Before we consult the TAG, I would like us to consult the work group (not the task force) and ask them what they think. I think that is a logical step to do first.
>
>
>
>

I'd like to hear from the task force too.


--
Surveillance is pervasive. Go Dark.

Received on Friday, 7 February 2014 05:02:26 UTC