Re: [whatwg] [Notifications] Notification.hasPermission() instead of Notification.permission

Just out of curiosity, what are we hoping that the use counter will show?
I'm presuming that every single app that uses the notification API will
make at least some use of Notification.permission, so it mostly seems like
it's going to show us how often the Notification APIs *in general* are used
in the wild. Is that going to be useful in making an API decision? If so,
how (what numbers would allow us to feel comfortable removing
Notification.permission)?

I ask this, because the paradigm I'm most used to is to define a new
replacement API, mark the old API as deprecated, then use UseCounters to
determine when enough sites have migrated to the new API that you feel
comfortable removing the deprecated API. Using UseCounters to measure raw
usage when there really isn't an alternative API available yet is not an
approach I'm familiar with.

-atw


On Tue, May 13, 2014 at 1:48 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> I thought I had replied to this. Seems I did not.
>
> On Tue, Apr 29, 2014 at 7:24 PM, Peter Beverloo <beverloo@google.com>
> wrote:
> > The Notification specification defines a static Notification.permission
> > accessor, which returns one of {granted, denied, default}. This requires
> > the browser to synchronously determine whether the page has permission to
> > show notifications, whereas checking this may be an asynchronous
> operation.
> > This is the case in Chrome.
> >
> > Before this becomes a paradigm, could we consider having a static
> > hasPermission() instead, returning a Promise?
>
> If use counter data shows we can do that, that'd be fine with me. Note
> that we expose a bunch of information from the underlying platform
> synchronously though.
>
>
> > I'll add a UseCounter to Blink for tracking Notification.permission
> usage,
> > but it will take some time before conclusive usage data comes in.
>
> Okay, please reply to this thread once we know what our options are.
>
>
> --
> http://annevankesteren.nl/
>

Received on Tuesday, 13 May 2014 12:00:02 UTC