Re: Constraints 2014 new slides

This all will be aired on the call, but let me agree with ekr for the 
record.  I don't see how this new proposal is an improvement on the 
existing one.  It is less powerful (can't couple constraints, only 
limited back-off), and to my eye the syntax more confusing.  We have an 
existing proposal that has been through a lot of discussion and we 
should not change it without very good reason, particularly if we want 
to get done this decade.

- Jim
On 3/27/2014 2:22 PM, Eric Rescorla wrote:
> 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 <mailto: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
>
>

-- 
Jim Barnett
Genesys