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 <[email protected]>
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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
