Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: forceAuthentication

7 views
Skip to first unread message

Kumar McMillan

unread,
May 13, 2013, 12:08:10 PM5/13/13
to Jedediah Parsons, Ben Adida, Shane Tomlinson, dev-id...@lists.mozilla.org

On Apr 11, 2013, at 11:07 AM, Jedediah Parsons <jpar...@mozilla.com> wrote:

>
> I'm +1 for prefixes like _experimental_ for our experimental parameters.
>
> I'm less sure about adding .enableCrazyStuff(). You would still need to label your experimental crazy stuff parameters as such, so this would establish one more hoop to jump through but without an obvious (to me) improvement for safety or clarity. Also, more on my mind, in the present situation, introducing such a function would require us touching the b2g client code, which at this point is going to be hard.
>
> /me goes to stand in the side of the room where we have _experimental_forceIssuer and _experimental_forceAuthentication

It sounds like consensus on this thread (and elsewhere) is to prefix experimental features and also document them. I'd like nudge on the documentation part: https://github.com/mozilla/browserid/issues/3384



>
> ----- Original Message -----
> From: "Ben Adida" <b...@adida.net>
> To: "Shane Tomlinson" <stoml...@mozilla.com>
> Cc: dev-id...@lists.mozilla.org
> Sent: Monday, April 8, 2013 10:59:00 AM
> Subject: Re: forceAuthentication
>
> Hi Shane,
>
> I haven't seen vendor prefixing for optional parameters before... we might
> be treading new ground.
>
> In a different context (web crypto), I've seen proposed an approach that
> involves an initial .enableCrazyStuff() call, then leaving the rest of the
> calls as they would be if the stuff becomes less crazy/experimental. That's
> the inspiration for my proposal.
>
> -Ben
>
>
> On Mon, Apr 8, 2013 at 7:54 AM, Shane Tomlinson <stoml...@mozilla.com>wrote:
>
>> I can see the value in this, it is kind of like an experimental DOM api
>> (mozPay) or experimental CSS declaration (-moz).
>>
>> As an alternative, can we make use of already existing, well understood,
>> vendor prefix conventions? This would allow other browser vendors to
>> experiment with new features as well:
>>
>> navigator.id.request({
>> mozForceAuthentication: true
>> },...
>>
>>
>> Shane
>>
>>
>> On 05/04/2013 04:08, Ben Adida wrote:
>>
>>> Hi team,
>>>
>>> So we have a lot of strong opinions on this thread, which is a good thing.
>>> Let me try to unravel/simplify a little bit. Let's keep an open mind (and
>>> that includes me.)
>>>
>>
>> ______________________________**_________________
>> dev-identity mailing list
>> dev-id...@lists.mozilla.org
>> https://lists.mozilla.org/**listinfo/dev-identity<https://lists.mozilla.org/listinfo/dev-identity>
>>
> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity

0 new messages