[webkit-dev] Notifications API

[Drew Wilson]

Has John sufficiently addressed people's concerns about this issue? Perhaps
some of the people who previously expressed concerns in the bug could chime
in here saying whether or not they are bought in now.

We'd like to move forward on getting a reviewer on this change, but we're
not certain what the next steps would be - we have a patch and we've done
our best to address concerns about our proposal. John's patch itself doesn't
provide any problematic behavior - it just enables individual user agents to
provide notification behavior on top of WebKit should they so choose.

So, what's the best way to move forward on this?

-atw

On Thu, May 21, 2009 at 11:17 PM, John Gregg <johnnyg at google.com> wrote:

> 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
>
>
>
> _______________________________________________
> 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/20090526/ba294c94/attachment.html>