I've been kicking around some ideas in this area. One thing you could do with persistent workers is restrict network access to the domain of that worker if you were concerned about botnets. That doesn't address the "I installed something in my browser and now it's constantly sucking up my CPU" issue, but that makes us no different than Flash :-P<div>
<br></div><div>Anyhow, addressing some of the other comments - I don't think that there's necessarily a problem with the async worker APIs as they stand, and I don't think we can easily retrofit synchronous APIs on top of their current execution model. The issue is that the core problem that Workers solve (parallel execution in a separate context from the page) is different than the problem that large web apps are trying to address (reduced latency).</div>
<div><br></div><div>SharedWorkers are overloaded to provide a way for pages under the same domain to share state, but this seems like an orthogonal goal to "parallel execution" and I suspect that we may have ended up with a cleaner solution had we decided to address the "shared state" issue via a separate mechanism.</div>
<div><br></div><div>Similarly, the "hidden page" mechanism seems to address a bunch of issues at once, and I'm wondering if we explicitly laid out the problems it's trying to solve, whether we might find a set of distinct smaller solutions that were more generally applicable. I just don't want to make the same design choices that we did with SharedWorkers, and end up with a monolithic solution that doesn't address the individual goals (i.e. cross-page sharing) in a developer-friendly manner.</div>
<div><br></div><div>So (and forgive me for restating), it seems like hidden page addresses the following problems that gmail and other large web apps are having:</div><div><br></div><div>1) Loading large amounts of Javascript is slow, even from cache.</div>
<div>2) Loading application state from the database is slow.</div><div>3) Sharing between pages requires going through the database or shared worker - you can't just party on a big shared datastructure.</div><div>4) There's no way to do things like new mail notifications, calendar notifications, local updates of your email inbox, etc when the browser is not open. Currently, even the most brain-dead shareware desktop calendar app can display an event notification, while web-based calendars are forced to rely on the user remembering to keep a browser window open.</div>
<div><br></div><div>Am I missing any other issues that hidden page is supposed to address?</div><div><br></div><div>A persistent worker could address #4 (perhaps with some limitations on network access to address security concerns). For #1/#2/#3, are we saying that web applications *must* install themselves (with the requisite user flow) just to get fast load times? That seems unfortunate - if I don't care about #4, I'd really like to be able to get the benefits of #1/2/3 without jumping through a user install.</div>
<div><div><br></div><div>-atw<br><br><div class="gmail_quote">On Mon, Jul 27, 2009 at 6:39 PM, 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 class="im"><br>
On Jul 27, 2009, at 7:13 PM, Aryeh Gregor wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not clear how the UI requirements here are different from<br>
persistent workers, though.  Those also persist after the user<br>
navigates away, right?<br>
</blockquote>
<br></div>
Persistent workers are even more of a security risk, since they are supposed to persist even after the browser has been restarted, or after the system has been rebooted. Persistent workers should be renamed to "BotNet Construction Kit".<br>

<br>
Regards,<br><font color="#888888">
Maciej<br>
<br>
</font></blockquote></div><br></div></div>