[whatwg] Installed Apps

[Michael Nordman]

On Tue, Jul 28, 2009 at 2:12 AM, Jonas Sicking <jonas at sicking.cc> wrote:

> 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.
>
> The only concern I see with this is that it permanently forces all
> windows from the same domain to run in the same process. As things
> stand today, if the user opens two tabs (or windows) and navigates to
> the two different pages on www.example.com, then a browser could if it
> so wished use separate processes to run those two pages. If we enabled
> this API the two pages would have to run in the same process, even if
> neither page actually used this new API.
>
> / Jonas


There are conflicting requirements along these lines that would need to be
resolved...

1) A nested iframe needs to run in the same process as its containing page.
2) A shared context needs to run in the same process as its client pages.

... but what if a nested iframe document in processA connects to a
sharedContext that has already been loaded into processB. Somethings gotta
give.

What if a sharedContext isn't gauranteed to be a singleton in the browser. A
browser can provide best effort at co-locating pages and sharedContexts, but
it can't gaurantee that, and the spec respects that.

The lesser gaurantee is that all directly scriptable pages (those from a
given set of related browsing contexts) WILL share the same sharedContext
(should the refer to it).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090728/d7001038/attachment-0001.htm>