W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2009

[whatwg] Installed Apps

From: Drew Wilson <atwilson@google.com>
Date: Sat, 8 Aug 2009 08:32:18 -0700
Message-ID: <f965ae410908080832nee41desa57feef587f3f2bd@mail.gmail.com>
2009/8/7 Michael Kozakewich <mkozakewich at icosidodecahedron.com>
>
>
> TO SUMMARIZE:
> -There are many other existing ways to notify
> -I'd suggest browsers have a Notification process with which open tabs
> register.
> -Registered open tabs could tell the browser to pop up a notification,
> perhaps with title text, body text, and image
> -Clicking the notification would set focus to the browser and to the
> notifying tab.
>
> To solve the lifetime issue:
> -Torn-off tabs run in separate processes
> -Processes may be re-skinned to appear as applications, but are really
> tabs.
> -Minimized/docked Processes taken off the taskbar/dock and into a
> notification area or Application Manager
> -If the rest of the browser is closed, the main process will stay on until
> the application tabs are closed
> -Browser's 'Application Manager' in notification area or taskbar/dock (and
> as a button in the main browser) holds all open application tabs
>
> Have I forgotten anything?
> Even without the application tabs, the notification process would be great
> to implement.
>

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.

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.

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.

-atw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090808/a96d07d7/attachment.htm>
Received on Saturday, 8 August 2009 08:32:18 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:15 UTC