Re: Conclusions from the constraints spec review

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 <mailto: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?

Yet people have been trying to apply it to simple settings APIs like 
PeerConnection's configuration, MediaStreamTracks and MediaRecorder. 
That tells me it is a misunderstood pattern to boot.

New settings, like peerIdentity, which we assumed would be a constraint, 
turn out not to fit.

Also, IANA-like extensibility and straightforward API documentation 
should not be mutually exclusive. I would argue one should not affect 
the other. i.e. a reader should not suffer for what should be mostly a 
back-end editor process. Doesn't make any sense.

There has been too much editor-focused design here IMHO and not enough 
reality check. There's going to be a lot of work to agree, implement and 
iron out the kinks of every new constraint that might come up. Measured 
against that work and timeline, why must registering the name in a 
registry be so quick, simple and formal? Are there that many browser 
implementers to keep track of? This doesn't add up to me. The cost 
benefit here is out of whack.

> 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
> -- 
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus eanuttehrotraiitny  
> eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha 
> iids  teoa stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  
> tfaokreg iyvoeunr, 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt 
> hwea lmka'n?  gBoutt  uIp  waanndt  wyeonut  thoo mken.o w *
> *

.: Jan-Ivar :.