Feedback from TPAC

At the TPAC we discussed Web Notifications within the Device APIs Working
Group. There were a couple of interesting points that seem logical to raise
here.

Firstly, the Permissions interface is an interesting concept but I was
wondering how people see this ultimately manifesting itself within the UA's
chrome? W3C groups, as a whole, are starting to overload the 'async
notification bar' concept. We are now using this paradigm in Geolocation,
Device APIs and Web Notification groups (off the top of my head). That's
excluding non-standard uses such as Translation extensions. Where possible
it would be best not to continue to design APIs that overload this prime UA
real estate for the risk that the default experience will be for users to
start getting stacked notifications within their web UA (e.g. what happens
if I go to a foreign webpage, that requires geolocation and also wants to
send notifications? 3 stacked notifications already?).

I was wondering whether you guys had considered designing out the
Permissions interface. For example, initially specifying a 'default grant'
model means that notifications do not need to be authorised before they are
shown. We then don't need to use the async notification bar concept.
Notifications can be revoked once shown for the first time ('Don't display
notifications from X again') and the whitelist/blacklist could be managed by
the UA itself. Since notifications have no long term impact on a user's
system I'd be fine to allow websites to push notifications without
explicitly giving them permission on the first attempt. Constantly granting
notifications could be both unintuitive and annoying.

Secondly, we discussed the potential to produce a generic push notification
system/api to allow server-side web apps, when not open, to push
notifications to the user's device. This would be particularly useful for
messaging systems such as webmail and IM apps. Additionally it could be
applied to RSS reader apps, price trackers and any number of other apps that
work while I'm not directly on them. Anything to reduce receiving the
innumerable emails per day that could easily have been communicated as
quick, unobtrusive notifications. Any such API would require queuing and
could be built on existing server technologies. Perhaps within this group
you could include hooks in to the Notifications API for HTML5 server-sent
events?

- Rich