W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2014

Re: [whatwg] Notifications: making requestPermission() return a promise

From: Brian Kardell <bkardell@gmail.com>
Date: Sun, 5 Oct 2014 09:57:56 -0400
Message-ID: <CADC=+jd9hx4PfeR=ppfPt=AkV7xQQmiQ+oWwa7GaUYUKO8TxsA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Andrew Wilson <atwilson@google.com>, WHATWG <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>, Jonas Sicking <jonas@sicking.cc>
On Oct 5, 2014 7:41 AM, "Anne van Kesteren" <annevk@annevk.nl> wrote:
>
> On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola
> <domenic@domenicdenicola.com> wrote:
> > So we should make a choice, as to whether we want developers to assume
they will always get permission (in which case it should reject upon
permission not being granted), or whether we want developers to ask the API
whether they were granted permission (in which case it should give back a
boolean fulfillment value or similar).
>
> How can they assume permission is always granted? It's up the user.
> It's a request from the developer and the user can say no. What's
> unclear about the name?
>

I think Domenic is saying "do we want to give the impression that you code
the happy path only in the then(), or do we assume you are asking an async
question for which an async answer is given with information for you to
disambiguate in the then() regardless of whether this is happy or not.

I originally expected denial to throw, I admit, but this is mainly because
it was guessing on an unestablished pattern. If we establish something
which can be applied widely, most of that is mitigated. I think the later
(async question that always answers in .then()) makes much more sense
especially given that https://notifications.spec.whatwg.org has 3 such
values (accepted, denied, default) - if there is algebra to be done we can
experiment with some good patterns inside .then() to make that easier.
>
> --
> https://annevankesteren.nl/
Received on Sunday, 5 October 2014 13:58:21 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:24 UTC