<br><br><div class="gmail_quote">2009/8/7 Michael Kozakewich <span dir="ltr"><<a href="mailto:mkozakewich@icosidodecahedron.com">mkozakewich@icosidodecahedron.com</a>></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
TO SUMMARIZE:<br>
-There are many other existing ways to notify<br>
-I'd suggest browsers have a Notification process with which open tabs register.<br>
-Registered open tabs could tell the browser to pop up a notification, perhaps with title text, body text, and image<br>
-Clicking the notification would set focus to the browser and to the notifying tab.<br>
<br>
To solve the lifetime issue:<br>
-Torn-off tabs run in separate processes<br>
-Processes may be re-skinned to appear as applications, but are really tabs.<br>
-Minimized/docked Processes taken off the taskbar/dock and into a notification area or Application Manager<br>
-If the rest of the browser is closed, the main process will stay on until the application tabs are closed<br>
-Browser's 'Application Manager' in notification area or taskbar/dock (and as a button in the main browser) holds all open application tabs<br>
<br>
Have I forgotten anything?<br>
Even without the application tabs, the notification process would be great to implement. <br>
</blockquote></div><br><div>One of the reasons I'm a proponent of running application script is the track record of one-size-fits-all, generic push solutions that are able to fulfill a broad range of use cases is fairly poor. If we are going to have the browser manage an incoming feed of push notifications, then I'd say at the very least we should allow web apps to register script handlers for those notifications, rather than try to build in static browser behavior. One could put limits on the execution of this script (perhaps only allow it to run for a limited period of time, for example), and provide UX to the end user such that there is transparency about the script running in the background of their browser.</div>
<div><br></div><div>I agree that the UX and Security issues around always-on persistent script are formidable, but I still think it's valuable to experiment in this area to see whether they can be overcome. Regardless, I think it's premature to latch onto a single potential use case for persistent script (static text + icon calendar notifications) and start building extensive alternative mechanisms to satisfy that case.</div>
<div><br></div><div>I think the takeaway from this thread is the recommendation that vendors could experiment in this area through the extension mechanism. I think once we've had a chance to build some app functionality on top of this, we'll have a better idea of the real-life use cases, and it would then be appropriate to see how/if those use cases could be satisfied in an alternate manner.</div>
<div><br></div><div>-atw</div>