<br><br><div class="gmail_quote">On Tue, Jul 28, 2009 at 1:38 AM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div class="im"><br><div><div>On Jul 27, 2009, at 10:51 PM, David Levin wrote:</div><br><blockquote type="cite"><div>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.</div>
<div><br></div><div>However, the first part sounds like it alone would be useful to web applications like GMail:</div> <div><br></div><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">The first, which should be<span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">generally useful, is the ability to have a hidden HTML/JS page running<br>
in the background that can access the DOM of visible windows. This<br>page should be accessible from windows that the user navigates to. We<br>call this background Javascript window a "shared context" or a<br>"background page". This will enable multiple instances of a web app<br>
(e.g. tearoff windows in Gmail) to cleanly access the same user state<br>no matter which windows are open.</span></blockquote></div><div><br></div><div>+ restrict things to the same security origin.</div><div><br></div><div>
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.</div>
<div><br></div><div>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).</div></blockquote></div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Maciej</div><font color="#888888"><div>
<br></div></font></div></blockquote></div><br><div>+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.</div>
<div><br></div><div>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.</div><div><br></div><div>* 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).</div>
<div><br></div><div>* another way to extend things could be to allow an appcache manifest to indicate which resources should be loaded into a shared context</div><div><br></div><div><br></div>