<!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.&nbsp; A 
  patch has been proposed to WebKit at <A 
  title="https://bugs.webkit.org/show_bug.cgi?id=25463&#10;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.&nbsp; 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.&nbsp; 
  <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>&nbsp;-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',&nbsp;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>&nbsp;</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&nbsp;delegate upgrades based on where they would be most 
suitable?</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT>&nbsp;</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&nbsp;renderer or 
JS engine&nbsp;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>