<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18812"></HEAD>
<BODY style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px"
id=MailContainerBody leftMargin=0 topMargin=0 CanvasTabStop="true"
name="Compose message area">
<DIV><B>From:</B> <A title=johnnyg@google.com
href="mailto:johnnyg@google.com">John Gregg</A> </DIV>
<DIV style="FONT: 10pt Tahoma">
<DIV style="BACKGROUND: #f5f5f5">
<DIV><B>Sent:</B> Monday, August 10, 2009 12:54 PM</DIV></DIV></DIV>
<DIV class=gmail_quote>
<BLOCKQUOTE
style="BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0pt 0pt 0pt 0.8ex; PADDING-LEFT: 1ex"
class=gmail_quote><FONT size=2 face=Arial></FONT>
<DIV><FONT size=2 face=Arial></FONT><FONT size=2 face=Arial></FONT><FONT
size=2 face=Arial></FONT><BR>I think it's appeared on this thread before, but
I'm currently working on an API to provide desktop notifications. A
patch has been proposed to WebKit at <A
title="https://bugs.webkit.org/show_bug.cgi?id=25463
CTRL + Click to follow link"
href="https://bugs.webkit.org/show_bug.cgi?id=25463">https://bugs.webkit.org/show_bug.cgi?id=25463</A>.<BR><BR>I
had originally proposed it to this list back in March under the context of
persistent workers, which had the same motivation that you describe:
background process while the application tab is closed. Now I think it
makes more sense to make this API available generically (pages included, as
the above WebKit patch does) subject to permissions, so that it will be
available to applications regardless of where they end up running.
<BR><BR>Desktop notifications are pretty useful even when the tab is active
but minimized, so it doesn't necessarily need to be wrapped up in a persistent
installation process, as long as permission can be
established.<BR><BR> -John</DIV></BLOCKQUOTE></DIV>
<DIV><FONT size=2 face=Arial></FONT><FONT size=2 face=Arial></FONT><BR><FONT
size=2 face=Arial>Are notifications really a renderer problem, as opposed to a
browser-UI problem? (e.g. 'Safari' or 'Chromium', rather than
'Webkit')</FONT></DIV>
<DIV><FONT size=2 face=Arial>Also, I don't know of any notifications (Outlook,
Messenger, AVG, TweetDeck, etc.) that require permissions, so I'd argue that
requiring permissions for notification would be arguably confusing. It doesn't
interrupt flow like alert() does.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Just in case I need to be set straight, here, I've
got a couple questions: If vendors implemented this, they would have to work on
their browsers, right? Is it easier for them to work on the rendering engine or
on the application, or is there no difference? Do they prefer to add
functionality to their rendering engine or to their application, or do they not
care? (For these, I'm working from the assumption that it doesn't noticeably
affect the UI, such as a new button or bar would.)</FONT></DIV>
<DIV><FONT size=2 face=Arial>And last: do they try not to touch the browsers, or
do they prefer to delegate upgrades based on where they would be most
suitable?</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>I think answering those questions would help me the
most, because at this point I don't know why they'd alter the renderer or
JS engine to handle popup JavaScript instead of altering the browser to
support what seems like a simple UI addition of pop-ups, but I do feel as though
they wouldn't like to change the browser process.</FONT></DIV>
<DIV><FONT size=2 face=Arial>(As a final point, it's been mentioned that such a
feature would become very popular, so many sites would implement it. It begs the
question of which option is best for handling the volume of notifications and
potentially abused notifications.)</FONT></DIV></BODY></HTML>