<span class="Apple-style-span" style="border-collapse: collapse; "><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
2) For multi-process browsers like Chrome, there seem to be limitations as to what can actually be accessed between processes (direct DOM access across process boundaries seems problematic for example). Do you have ideas about how to address this, since assumedly the page calling getInstalledApp() could be running under some arbitrary process?</blockquote>
<div><br></div><div>Even with single-process browsers you would have to handle threading issues in a way that is just not done in all browsers yet.</div><div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
For a) - Having some way to load large amounts of cached javascript quickly in a new page seems like an issue that would be nice to address in general, not just for pages that install hidden pages. Are there other approaches worth trying here?</blockquote>
<div><br></div><div>Loading of cached JavaScript isn't really that slow. I think the real issue here is client state. It's often a good idea to have a copy of running scripts in each process for stability anyway. However, cached parsing/pre-compilation (if available) of scripts might be a generally good idea. Perhaps some kind of process cloning like *nix forks?</div>
<div><br></div><div>IMHO, this could be solved cleaner and more memory efficient way with some form of persistent workers rather than a "hidden" page. But I might be missing something.</div></span><br><div class="gmail_quote">
On Tue, Jul 28, 2009 at 1:30 AM, 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;">
This sounds really powerful, and seems like a natural evolution of some of the stuff we've discussed previously for persistent workers. A few comments/notes:<div><br></div><div>1) It sounds like this background page would act like any other web page with respect to its processing model (i.e. like other pages, script running in this page would be limited as to how long it can run, as opposed to workers which can run for any arbitrary length of time). This seems reasonable, especially since this page could assumedly still create workers if it need to do true background processing. It's really more of a "hidden" page than a "background page"?</div>
<div><br></div><div>2) For multi-process browsers like Chrome, there seem to be limitations as to what can actually be accessed between processes (direct DOM access across process boundaries seems problematic for example). Do you have ideas about how to address this, since assumedly the page calling getInstalledApp() could be running under some arbitrary process?</div>
<div><br></div><div>3) This approach has another advantage over something like workers in that a hidden page can do cross-domain access/sharing via iframes, whereas workers don't really have any facility for cross-domain access.</div>
<div><br></div><div>4) I had a quick question/clarification about the motivation behind this - aside from the advantages described above, it sounds like the specific problem you are solving by a hidden page is a) you don't have to load javascript in a new page (which I'm assuming must be slow), and b) you don't have to load client state in the new page.</div>
<div><br></div><div>For a) - Having some way to load large amounts of cached javascript quickly in a new page seems like an issue that would be nice to address in general, not just for pages that install hidden pages. Are there other approaches worth trying here?</div>
<div><br></div><div>For b) - How much client state are we talking about? If you were to pursue this approach using workers to maintain client state, how much data would you expect to be transferred to the client app on startup? We're seeing fairly low latency for client<->worker communication, so in theory it shouldn't be a huge source of slowdown.</div>
<div><br></div><div>I agree that the programming model of the hidden page is much cleaner/more familiar than rewriting applications to use asynchronous messaging, so that may be sufficient motivation for this.</div><div>
<br>
</div><div>-atw<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Mon, Jul 27, 2009 at 11:50 AM, Michael Davidson <span dir="ltr"><<a href="mailto:mpd@google.com" target="_blank">mpd@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello folks -<br>
<br>
I'm an engineer on the Gmail team. We've been working on a prototype<br>
with the Chrome team to make the Gmail experience better. We thought<br>
we'd throw out our ideas to the list to get some feedback.<br>
<br>
THE PROBLEM<br>
<br>
We would like to enable rich internet applications to achieve feature<br>
parity with desktop applications. I will use Gmail and Outlook as<br>
examples for stating the problems we hope to solve.<br>
<br>
-- Slow startup: When a user navigates to <a href="http://mail.google.com" target="_blank">mail.google.com</a>, multiple<br>
server requests are required to render the page. The Javascript is<br>
cacheable, but personal data (e.g. the list of emails to show) is not.<br>
New releases of Gmail that require JS downloads are even slower to<br>
load.<br>
-- Native apps like Outlook can (and do) run background processes on<br>
the user's machine to make sure that data is always up-to-date.<br>
-- Notifications: Likewise, Outlook can notify users (via a background<br>
process) when new mail comes in even if it's not running.<br>
<br>
A SOLUTION<br>
<br>
Our proposed solution has two parts. The first, which should be<br>
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.<br>
<br>
Additionally, we'd like this background page to continue to run after<br>
the user has navigated away from the site, and preferably after the<br>
user has closed the browser. This will enable us to keep client-side<br>
data up-to-date on the user's machine. It will also enable us to<br>
download JS in advance. When the user navigates to a web app, all the<br>
background page has to do is draw the DOM in the visible window. This<br>
should significantly speed up app startup. Additionally, when<br>
something happens that requires notification, the background page can<br>
launch a visible page with a notification (or use other rich APIs for<br>
showing notifications).<br>
<br>
WHY NOT SHARED WORKERS<br>
<br>
Shared workers and persistent workers are designed to solve similar<br>
problems, but don't meet our needs. The key difference between what<br>
we're proposing and earlier proposals for persistent workers is that<br>
background pages would be able to launch visible windows and have full<br>
DOM access. This is different from the model of workers where all<br>
interaction with the DOM has to be done through asynchronous message<br>
passing. We would like background pages to be able to drive UI in a<br>
visible window using the techniques (DOM manipulation, innerHTML) that<br>
are common today. We believe that more apps would be able to take<br>
advantage of a background page if they didn't require rewriting the<br>
app in the asynchronous, message-passing style required by workers.<br>
Allowing the background page to drive the UI by doing direct DOM<br>
manipulation is a more common programming style. For apps that don't<br>
need the benefits of multiple threads provided by shared workers, this<br>
will give the benefits of fast startup and the benefits of running in<br>
the background (like showing notifications) without the downside of<br>
the worker programming model.<br>
<br>
The concepts here are similar to permanent workers, but with a<br>
different programming model.<br>
<br>
IMPLEMENTATION AVENUES<br>
<br>
For now, we have a simple API in Chrome. This is meant as a prototype<br>
of the concepts, not as a final API.<br>
<br>
-- installApp(uri, name) Fetches the HTML page at uri, and runs it as<br>
a hidden window. Currently this window is loaded when the machine<br>
starts. This should eventually involve permissioning UI, but this is<br>
not implemented. name is a name that can be used to get access to the<br>
hidden window.<br>
-- getInstalledApp(name) Returns a reference to the background page,<br>
or null if the app is not installed.<br>
-- removeInstalledApp(name) The moral equivalent of window.close() for<br>
a background page.<br>
<br>
We might migrate to a model where webapps can be installed as Chrome<br>
extensions instead of using a Javascript call to install the app.<br>
<br>
Another alternative we've discussed is allowing authors to specify in<br>
their AppCache manifest that a given page should be an always-loaded<br>
background page. This seems like a natural fit since the AppCache<br>
manifest is where authors describe the attributes of various parts of<br>
their app.<br>
<br>
KNOWN ISSUES<br>
<br>
As mentioned in earlier discussions about persistent workers,<br>
permissioning UI is a major issue.<br>
<br>
FEEDBACK<br>
<br>
We would like to know if others would find this functionality useful.<br>
Does anyone have an idea for a better API?<br>
<font color="#888888"><br>
<br>
Michael<br>
</font></blockquote></div><br></div></div></div>
</blockquote></div><br>