[whatwg] Installed Apps

[Michael Nordman]

On Tue, Jul 28, 2009 at 1:38 AM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Jul 27, 2009, at 10:51 PM, David Levin wrote:
>
> It sounds like most of the concerns are about the 2nd part of this
> proposal: allowing a background page to continue running after the visible
> page has been closed.
>
> However, the first part sounds like it alone would be useful to web
> applications like GMail:
>
> The first, which should begenerally useful, is the ability to have a
> hidden HTML/JS page running
> in the background that can access the DOM of visible windows. This
> page should be accessible from windows that the user navigates to. We
> call this background Javascript window a "shared context" or a
> "background page". This will enable multiple instances of a web app
> (e.g. tearoff windows in Gmail) to cleanly access the same user state
> no matter which windows are open.
>
>
> + restrict things to the same security origin.
>
> It sounds similar in concept to a share worker except that it runs in the
> main thread and is more concerned with dom manipulation/state while workers
> have typically been thought of as allowing background processing.
>
> It seems that the lifetime of this could be scoped, so that it dies when it
> isn't referenced (in a similar way to how shared worker lifetime is scoped).
>
>
> This idea actually sounds reasonably ok, and I think I once proposed
> something like this as an alternative to shared workers as the way for
> multiple app instances to share state and computation.
>
> It's really the bit about invisibly continuing to run once all related web
> pages are closed that I would worry about the security issues.
>
> Regards,
> Maciej
>
>
+1 seperating the "load-at-startup" and
"persist-beyond-connected-page-close" from the more generally applicable
feature to "connect to a directly scritable shared context from multiple
pages". Minus the lifetime questions, I don't think there's anything
terribly controversial about this... very similar to an invisible iframe
that's must be from the same-origin as the referencing page. I think this
could be a very valuable feature in general.

Gmail does really want permissions to run in the background... but I think
that could be layered on top of the more primitive "shared context" feature.

* one way to 'extend' things could be to allow a persistent worker (which
has permissions to run in the background) to load a shared context and hold
a refernce to it to prevent the shared context from closing (note: the
persistent worker wouldn't be able to directly script that shared context,
just bootstrap it and keep it alive).

* another way to extend things could be to allow an appcache manifest to
indicate which resources should be loaded into a shared context
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090728/f3d18979/attachment.htm>