[webkit-dev] Notifications API

[John Gregg]

I circulated a proposal several weeks ago which specified a notifications
API for workers (desktop toasts), and the feedback was that (a) persistent
workers are still far away, (b) is a notifications api necessary given it's
basically a new window?, and (c) have we thought through the security
issues? (https://bugs.webkit.org/show_bug.cgi?id=25463)   I've tried to
answer these questions but some points have remained sticky, so I'm reaching
out again in search of consensus.

As far as workers go, I've modified the proposal (and patch) to attach the
notifications object to DOMWindow as well as WorkerContext, so that both
regular pages can access it as well and this is not worker-specific.

On the security question, a substantial amount of thought has gone into how
to prevent unwanted popups (and in general how to control access to HTML5
application features).  We think user opt-in on an origin-basis is the best
policy and it's what we plan to do in Chromium; the WebKit interfaces are
structured so that the policy is up to the user agent via a
NotificationProvider interface.

The API & use case question seems to be the big one remaining open.  On the
use case front, there are several Google products interested in using it
(Calendar reminders, Gmail alerts, etc.)  We also see Mozilla Jetpack
demoing an API very similar to the one I've proposed in their recent
release.  So I think there is plenty of reason to believe this feature would
be used to greatly enhance applications.

Last, if the feature is included should the interface be *
window.notifications.create*() -- my proposal (also Jetpack's API) -- or *
window.open*("style=notification"), the alternate suggestion?  Here are my
thoughts supporting the former:

   - Notifications will evolve: the first generation is text+icon only, the
   second generation is small HTML bubbles, maybe something else later.  While
   small HTML bubbles might align well with window.open, text+icon toasts
   don't.  For some platforms we can get both, for some only the simple form.
   Logically what an app developer will do is check what notification options
   are available on the platform, then use the most full-featured option
   available.  This check should be easy to do, and the result shouldn't send
   them to different existing APIs to find the closest match, if we can help
   it.  I think providing a notifications object to encapsulate the feature
   makes more sense.
   - Opening a new window for an HTML notification is only one possible
   implementation.  In the future (or now) a user agent may want to toast up
   the HTML block on the taskbar, or in a corner of an existing tab, or append
   it to a stream in a dedicated notification panel.  Semantically the service
   provided to the app developer is "alert the user using the HTML at this
   URL", and defining the interface to match gives us the most flexibility to
   implement in the future without being tied to a particular existing notion.

Other thoughts?

Thanks,
-John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090521/7ec84f0e/attachment.html>