[webkit-dev] Web Notifications API

Thu Feb 9 10:42:19 PST 2012

On Wed, Feb 8, 2012 at 4:58 PM, Jon Lee <jonlee at apple.com> wrote:

> Hi WebKit!
>
> I am interested in refactoring the API for web notifications, and would
> like your feedback. We are working on getting permission to join the Web
> Notifications working group, but thought that while doing that I could try
> to get some general consensus from the WebKit community about these changes
> prior to proposing them to the WG.
>
> The basic intents of the refactoring are to a) align the API with the
> design of recent APIs in the WebApps WG and elsewhere, and b) to simplify
> the API by removing unnecessary bits. With these changes I think we can put
> the API in a good place for future enhancements.
>
> ====
> Here are the proposed changes:
>
> 1. Move the factory method to a constructor function.
>
> new WebKitNotification(title, body, [optional] iconURL)
>
> This is similar to the spec [NOTIF], except that the icon URL has been
> moved to the end as an optional argument. Notification platforms may choose
> not to load the URL for privacy reasons, and I think it should not be a
> required component for a text notification.
>

One note: if we're going to change the API at all, I'd like to see us
change it exactly once - to the draft API defined by the standards body. So
I'd be opposed to a transitional phase window.webkitNotifications ->
WebKitNotification() -> <draft standard>. Otherwise, applications using
this API have to try to support all 3 APIs to deal with legacy browsers.

>
> 2. Remove HTML notifications.
>
> It has been removed from the spec, and we don't intend on ever supporting
> HTML notifications. I brought this issue up before; is there an update on
> this front from any other platforms?
>
> 3. Use static functions on the notification constructor for permissions
> checks.
>
> By moving them there, it allows us to remove window.webkitNotifications
> and the NotificationCenter class, cleaning up the API.
>
> 4. Adjust the permission functions.
>
> WebKitNotification.permissionLevel() --> String
>
> Similar to checkPermissions(), synchronous call. The name aligns with
> similar functionality in the DAP Feature Permissions spec [FEAT], but
> scoped specifically to Web Notifications. Returns one of three strings:
> "granted", "denied", and "default". This follows the current best practice
> from the WebApps WG where strings are being used instead of enums.
>

Nit: Can you clarify what "default" means? I think it means "the user has
not granted permission yet, but you can still create notifications and they
will be queued until such time that the user chooses to grant permission".
Maybe something clearer than "default", like "not-granted" (the reason why
"default" concerns me is a UA may decide to provide notification permission
to all origins as the default configuration, but it seems like this would
not map to "default" but rather to "granted".

>
> WebKitNotification.requestPermission(callback)
>
> An asynchronous call, as it is currently. The callback specified includes
> one argument which represents the permission, similar to the return values
> in permissionLevel(). (Currently it is just a void callback.) If the user
> had already made a policy decision, then the callback is invoked
> immediately (with either "granted" or "denied"). Otherwise the UA may ask
> the user for permission, and the callback is invoked when the user makes a
> decision (cancelling the request does not invoke the callback). Any
> notifications posted in the meantime would be queued until then. Multiple
> calls to this function should just result in one visible request.
>

Just a note, since I'm not sure what "immediately" means - the callback
should always be invoked asynchronously even if permissions have already
been granted/denied. I'm slightly uneasy about queueing notifications - I
like the current spec's behavior where notification.show() results in an
error event if permission is not granted. Otherwise, if the user changes
their permission configuration for an origin (from "granted" to
"not-granted") the app would not be notified that its notifications are not
being displayed - they would just be silently queued (apps would then have
to check permissions themselves before posting every notification if they
wanted to detect this case - they couldn't just rely on the error callback).

>
> 5. Remove replaceId.
>
> This could already be done by canceling a previous notification and
> posting a new one. The idea of replacing a notification with another one
> without alerting the user is a feature that we don't intend on supporting.
>

This is an important feature when you have multiple web pages open to the
same domain, so I would be strongly opposed to removing this. For example,
let's say you have facebook open in two windows, and facebook would like to
provide a notification to you of some event - by using replaceId, facebook
can ensure that you receive only one notification for the event. Otherwise,
you'd get a notification from every single window. I added notifications
support to Gmail, so I'm happy to discuss this use case further if you need
further justification.

>
> 6. Improve show() behavior.
>
> Calling show() when the site has been denied permission should call
> onerror(). If no decision was made, then the notification should remain
> queued, and only until after the user has decided should onshow() or
> onerror() be called. I also think show() can only be used once. Subsequent
> invocations should call onerror().
>

See my concerns about this behavior above. I understand the motivation
behind this, however - you'd like for the user to not lose any
notifications that might be generated while waiting for the permission to
be granted. I'd say it's not particularly difficult for applications to do
this queuing themselves if desired.

>
> 7. Remove ondisplay.
>
> The spec uses onshow instead.
>
> ====
> More minor implementation details:
>
> 1. Rename NotificationPresenter to NotificationClient.
>
> This is just to make it follow the nomenclature of all page clients.
>
> 2. Simplify Notification and merge NotificationContents into it.
>
> I am unsure what the purpose of moving the data out into a separate class
> was, but it seems unnecessary.
>
> ====
>
> If you got this far, thanks for reading. Any and all feedback welcome!
>
> Regards,
> Jon
>
> [FEAT] http://dev.w3.org/2009/dap/perms/FeaturePermissions.html
> [NOTIF]
> http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120209/b2a28fc0/attachment.html>