Re: Thoughts on WebNotification

On Thu, Jun 24, 2010 at 11:38 AM, Doug Turner <doug.turner@gmail.com> wrote:

> I have been thinking a bit on Desktop Notifications [1].  After reviewing
> the Web Notification specification [2], I would like to propose the
> following changes:
>
>
> 1) Factor out the permission api into a new interface and/or spec.  The
> ability to test for a permission without bring up a UI would improve the UX
> of device access.  I could imagine implementing this feature for use with
> Geolocation as well as notifications.  For example:
>
> interface Permissions {
>
> // permission values
> const unsigned long PERMISSION_ALLOWED = 0;
> const unsigned long PERMISSION_UNKNOWN = 1;
> const unsigned long PERMISSION_DENIED  = 2;
>
> void checkPermission(in DOMString type, in Function callback);
>
> }
>
> Then we could do something like:
>
> navigator.permissions.checkPermission("desktop-notification",
> function(value) {});
>
> or
>
> navigator.permissions.checkPermission("geolocation", function(value) {});
>
>
I like this idea, I think it's definitely preferable to a one-off permission
system just for notifications.

Your proposal doesn't have a way to explicitly request permission.  Would
you be willing to add that, with the recommendation that it only take place
on a user gesture?  I don't think this eliminates the ability to implement
request-on-first-use, if that's what Mozilla prefers, but I also still think
there is benefit to allowing permissions to be obtained separately from
invoking the API in question.

The bigger question is, are other features interested?  Would the
Geolocation spec consider using something like this for permissions?


> 2) Add language to the spec to indicate that the DOMStrings used
> |createNotification| are not to include any mark up.  Basically,
> implementations are going to hand off notifications to system-level
> services.  For example, on the Mac, GROWL does not handle any mark up...
> their API just takes plain strings.  I'd like to see the API reflect this
> reality.  Something like "the |title| and |body| arguments are to be treated
> as plain text"... or some such language.
>
>
Although the group isn't chartered to deliver the spec forward, FWIW I agree
with this suggestion (it was always the intent) and have made this language
explicit in the editor's draft.


>
> 3) Move Web notifications to a version 2 of the specification.  For the
> most basic use cases, this API isn't required and a web developer could use
> the more base API to simulate this.  Furthermore, as I mentioned above, many
> system-level notification services know nothing about rendering html.


Though I think web content still makes sense for notifications coming from a
web browser, and would want to publish an API which drives things in that
direction, I think this is reasonable if it will encourage greater
implementation of the basic API.  As long as the text+icon API we use
doesn't cut off that avenue, and I think what we have now meets that.

 -John