Re: Constraints 2014 new slides

I misread my calendar. I will be on the call. With that said.



On Thu, Mar 27, 2014 at 10:49 AM, Dominique Hazael-Massieux <dom@w3.org>wrote:

> On jeu., 2014-03-27 at 09:09 -0700, Eric Rescorla wrote:
>
> > At a high level, I'm trying to understand the motivation for this
> > change.
> > Any significant revision to the constraints syntax comes with a really
> > large cost for application programmers, who will have to somehow
> > have to figure out which constraints syntax to offer. These syntaxes
> > appear to be incompatible in the sense that if you were to supply a
> > new-style syntax to an old implementation, it would likely choke and
> > vice versa.
>
> Is there any browser that actually supports the current constraint
> syntax?


My understanding was that both Chrome and Firefox supported
limited versions.



> My understanding was there isn't, and as a result, there must be

very few (if any) real applications that rely on the current syntax
> (beyond {video: true, audio: true} which I understand the new proposal
> would support).




> > the major benefit of this is better WebIDL conformance
>
> I think the improve readibility and writability for developers is also a
> pretty important benefit.


This seems extremely marginal.


 > WRT to the details:
> > As I mentioned in a previous message, this doesn't seem to be
> > generalizable to talk about multiple instances of audio and video.
>
> Is that something the current constraints proposal support?


No, but it's easily added.



>  > I share Cullen's concern about not being able to list a set of
> > devices in order of preference. This is basic functionality.
>
> Doesn't "prefer" combined with sourceId give that?


Not that I can tell based on the discussion so far.




>  > In summary, I oppose adopting this proposal at this time.
>
> Could you clarify whether:
> * you think we should stick with the current constraints syntax and
> semantics (and only consider evolutions backwards compatible with it)
> * you don't want to agree one way or another now on the right approach
> for constraints now
>
> (it's unfortunate to combine not being on the call, and voicing your
> concerns late in the thread)


This complaint would have a lot more force if Jan-Ivar's current
proposal had been posted sometime prior to 17 hours ago.


 >  I'm not a big
> > fan of the current syntax, but if we're going to change a bunch of
> > stuff we should take a serious look at what we are optimizing for and
> > then build something that matches that.
>
> AFAICT, that's exactly what J-I has been doing; he has been specifically
> asking for what "requirements" the solution need to satisfy:
> http://lists.w3.org/Archives/Public/public-media-capture/2014Mar/0099.html
>
> Adding new requirements when he comes up with one solution doesn't lead
> to progress.
>

Well, we already have one solution, the one that's in the doc. If it's
progress you're after, sticking with that would be the fastest thing.

I would have thought "actually be an improvement" was a requirement that
didn't need to be stated.

-Ekr