[webkit-dev] Notifications API

[Maciej Stachowiak]

On May 26, 2009, at 2:01 PM, Drew Wilson wrote:

> 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?

I sent some comments, Sam will chime in as well.

Regards,
Maciej

>
>
> -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
>
>
> _______________________________________________
> 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/4dc62b19/attachment.html>