- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Thu, 27 Mar 2014 18:49:14 +0100
- To: Eric Rescorla <ekr@rtfm.com>
- Cc: Jan-Ivar Bruaroey <jib@mozilla.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
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 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. > 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? > 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? > 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) > 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. Dom
Received on Thursday, 27 March 2014 17:49:33 UTC