<div class="gmail_quote">On Tue, Jul 28, 2009 at 1:01 PM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com">atwilson@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div></div>
<div>2) Loading application state from the database is slow.</div></blockquote><div><br></div><div>Do we know why 1 and 2 are true? Can it be fixed?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div></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>
</blockquote><div><br></div><div>Yes, but a background page keeps a lot of state in memory semi-permanently. It's not acceptable for any web page to have the power to use significant system resources even after it's been closed. </div>
<div><br></div><div>The most contentious part of this proposal is keeping the page open after all it's parent pages have been closed. #3 only needs background pages to be open as long as it's parent pages are open. #4 can be somewhat solved by this, but there are other less resource intensive solutions to that as well.</div>
<div><br></div><div>Something like Aaron's proposal where "t<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">he lifetime of the page could be refcounted by pages referencing it" seems reasonable though. It doesn't solve the initial startup problem, but it does solve #3, which would allow for making things like popping out an email to it's own window fast.</span></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">In addition, putting this behind an install UI like extensions seems fine to fix the startup case and #4, although I agree that you shouldn't need to "install gmail" for it to load quickly.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">I'd like to understand the underlying reasons for #1 and #2. As Jonas said, there may be alternative solutions that are less prone to abuse of system resources. For example is loading cached JS so slow because it needs to hit disk? That could be solved by an AppCache extension that pins resources in memory if possible.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Ojan</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div>-atw</div><div><div><div></div><div class="h5"><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" target="_blank">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><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></div></div>
</blockquote></div><br>