Re: static permission functions on Notification (was Feedback from Safari on Web Notifications)

On Tue, Mar 13, 2012 at 3:17 AM, Marcos Caceres <w3c@marcosc.com> wrote:
>
> On Tuesday, 13 March 2012 at 00:32, Jon Lee wrote:
>
> > I've been trying to scan through other specs, and don't see others who
> are using the feature permission spec. And as far as I know there are no
> implementers of that spec. I don't think we should block ourselves on the
> completion and adoption of it to support notifications.
> >
> > Does anyone else have an opinion on this?
> >
>
>
> I agree. I think the permission spec, if it ever gets completed, will
> probably look to Web Notifications for guidance, not the other way around.
>
>
That is probably true -- FYI for those that are new to the group, the
history of the Feature Permissions spec is that it was refactored out of
the Notifications spec by this WG and then transferred over to the devices
WG.  The content hasn't changed too much from the original inline version.

Practically speaking, it likely doesn't matter since yes notifications
would be the only feature at first to use the permissions module, and
Notifications implementers would be the first implementers of Permissions.
 Either way we go we are setting the example of how we think it should be
done, so we should settle the API discussion rather than just choosing the
shortest path to implementation.

On Tuesday, 13 March 2012 at 00:32, Jon Lee wrote:

> I believe we should not at this time depend on that spec for permissions
> behavior. From a general perspective, it opens the door for bad user
> experience, and I think this kind of API should only be available when
> necessary. Using the feature permissions spec makes it too easy to add new
> features that don't need it, and which could be handled through better API
> design, like in geolocation. UAs could either pummel the user with
> permission requests, or force the user to allow all features at once.


Having a central permissions API has no effect on the UAs likelihood to
pummel or force users; that would be a poor implementation.  It also
doesn't affect rogue features creeping in, since valid features are to be
enumerated in the spec.

It does make it easier for permissions flows for different features to be
consistent in a UA and easier for the user to understand how permissions
work.  The primary rationale for the central permissions API is this:
allowing a web site to request all of its permissions once rather than
requiring the site to ask the user N times is a better experience for
users.  Looking at other systems (browser extensions, mobile apps, etc.),
this pattern has been established before.