Re: The UNKNOWN mandatory constraint behavior is a footgun

How does "making it harder to use an API" meet any requirements at
all? I really don't understand that request.
You're assuming Web developers are dumb and if you make it hard enough
to use something, they will stop using it.
Instead what will happen is that they search StackOverflow for
solutions on how to achieve a certain goal and if that involves
mandatory constraints, they will get a recipe there on how to achieve
it, copy it and be done.
How hard it is to use an API has no (I repeat: *absolutely no*)
influence on how often an API is being used.
Let's not kid ourselves.

So, in view of this: go ahead and try to make it harder. Us Web Devs
really like a challenge - it's what we've become used to when dealing
with Web standards and browsers. :-)

Silvia.



On Fri, Nov 15, 2013 at 6:56 AM, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:
> I’m fine with this.  How about other people?  I thought we agreed on
> Thursday to make mandatory constraints harder to use, but it was very late
> at night.  I think it was Dom who suggested that some constraint should not
> be able to be made mandatory.  If we agree not to make mandatory constraints
> harder to use, and want to allow all constraints to be mandatory, while
> changing _only_ the behavior of unknown mandatory constraints, then what
> Jan-Ivar is proposing makes sense.
>
>
>
> Two questions though:
>
> 1.        Do we want a different consent prompt to the user in the case
> where there is an unknown mandatory constraint?  If we do, then we have to
> figure out  how gUM can signal that information to the UA or app.
>
> 2.       How should an unknown mandatory constraint behave in
> applyConstraints()?  There is no user involved here.  (In the current draft,
> the failure callback will be called.)
>
>
>
> -          Jim
>
>
>
> From: Jan-Ivar Bruaroey [mailto:jib@mozilla.com]
> Sent: Thursday, November 14, 2013 5:11 PM
> To: public-media-capture@w3.org
> Subject: The UNKNOWN mandatory constraint behavior is a footgun
>
>
>
> I realize I shot my message in the foot by not being more precise in my
> subject line earlier.
>
> It is the dictated treatment of mandatory constraints *unknown to the UA*
> that I'm highlighting a problem with.
>
> I 100% support the existing spec behavior of mandatory constraints for
> constraints that the browser implements, and I would hate to see us make
> them harder to use. If an app doesn't want to support a resolution, lets not
> make it harder for it to declare this.
>
> I also don't think browsers should police constraints, taking control away
> from webapps over which ones can be declared as mandatory. Power to the
> webapp!
>
> In other words, webapps should be free to discriminate, without having to
> deal with the "bug" that browsers blind to a new constraint type will fail
> 100% of the time, rather than grant access to the best available device
> based on the information it does understand (which may just work, either
> directly or with the user's help).
>
> I urge you to re-read my suggestion below if this wasn't clear the first
> time.
>
> Sorry for any confusion this caused,
>
> .: Jan-Ivar :.
>
> On 11/12/13 1:04 AM, Jan-Ivar Bruaroey wrote:
>
> I've implemented a strict interpretation of the spec's mandatory constraint
> that treats unknown keys as unsupported, I've tried it, and I think it is
> wrong.
>
> Scripts should just work, so you mustn't use 'mandatory' unless you also
> code up a fallback, yet we've made it the thing people try first (with its
> marginally preferable syntax).
>
> With future constraints coming, 'mandatory' is an invite to fail on a subset
> of browsers, a honeypot for newbie webdevs who test only their favorite
> browser(s).
>
> At the same time, 'mandatory' is a sucky api for asking what the browser
> supports, because you can't just ask, you have to be prepared to do.
>
> So it is bad for simple devs who just want to do, and bad for advanced devs
> who just want to ask.
>
> It also goes against webidl (maybe even against the web), requiring
> implementers to circumvent dictionaries, which, as Travis points out,
> disallow detection of unknown keys for this very reason (future-proofing).
>
> ---
>
> Now, all this may be justified, if there were no other way.
>
> But I think there is another way:
>
> MINIMALLY:
>
> Browsers must have a getCapabilities() query that returns which constraints
> it implements.
> We clarify that mandatory constraints are webidl dictionaries, e.g. unknown
> keys are ignored.
> Browsers must include in webidl only the keys they actually implement.
>
>
> The simple dev (with no fallback) can now just do, and things work as well
> as possible. This is the best outcome for this person.
>
> The advanced dev (with fallback) uses getCapabilites() and then uses gUM
> with 'mandatory' to narrow sources only by the constraints the browser
> supports, giving them the control needed to make intelligent fallbacks.
>
> This works with webidl, and is webby.
>
> IDEALLY:
>
> I'd love to see us go further and adopt a constraint format without the
> now-confusing name 'mandatory', like my "dictionaries of decreasing
> preference" proposal
> http://lists.w3.org/Archives/Public/public-media-capture/2013Nov/0052.html
>
>
> .: Jan-Ivar :.
>
>
>
> --
> .: Jan-Ivar :.

Received on Friday, 15 November 2013 00:12:06 UTC