<div class="gmail_quote"><br></div><div class="gmail_quote">On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch">ian@hixie.ch</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">On Mon, 17 Aug 2009, Dmitry Titov wrote:<br>
><br>
> Currently there is no mechanism to directly share DOM, code and data on<br>
> the same ui thread across several pages of the web application.<br>
> Multi-page applications and the sites that navigate from page to page<br>
> would benefit from having access to a shared "global script context"<br>
> (naming?) with direct synchronous script access and ability to<br>
> manipulate DOM.<br>
<br>
</div>This feature is of minimal use if there are multiple global objects per<br>
application. For instance, if each instance of GMail results in a separate<br>
global object, we really haven't solved the problem this is setting out to<br>
solve. </blockquote><div><br></div><div>I think you assume some specifics... Lets say there is only 1 "GMail window" and a couple of 'compose message' ones - the proposal surely helps this scenario. It also helps the GMail window to navigate between its own views. Running multiple "GMail windows" may in fact be considering running 2 "GMail applications" in which case having separate context for them might be even desirable.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">We can already get a hold of the Window objects of subwindows (e.g.<br>
for popping out a chat window), which effectively provides a global<br>
object for those cases, so it's only an interesting proposal if we can<br>
guarantee global objects to more than just those.</blockquote><div><br></div><div>The proposal says keep the global object across navigation in the same browsing context. Also, it provides lifetime of the global context that is not limited by the lifetime of one of the windows. That is useful and not possible today.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
However, we can't. Given that all frames in a browsing context have to be<br>
on the same thread, regardless of domain, then unless we put all the<br>
browsing contexts on the same thread, we can't guarantee that all frames<br>
from the same domain across all browsing contexts will be on the same<br>
thread.<br>
<br>
But further, we actually wouldn't want to anyway. One of the goals of<br>
having multiple processes is that if one tab crashes, the others don't. We<br>
wouldn't want one GMail crash to take down all GMail, Google Calendar,<br>
Google Chat, Google Reader, Google Search, and Google Voice tabs at once,<br>
not to mention all the blogs that happened to use Google AdSense.<br>
</blockquote><div><br></div><div>GMail, Calendar and Reader are currently very separate applications on separate origins. Popup chat windows will be killed today if their opener (GMail window) crashes. Worse, they will be killed even if the opener will be closed - since they are on life support from it - and windows get closed way more often then crashing. Proposal addresses that.</div>
<div><br></div><div>I'm not sure there is, in fact, a deep technical reason behind some apps existing in a shared origin like <a href="http://www.google.com">www.google.com</a>. It might improve efficiency of some parts of Google infrastructure, but even if it is, it looks like Google is a special case, and we should not design API for the way Google does things currently. There should be ways to tell that specific set of pages form an "application". Current way to do that, judging from the spec, is same-origin policy - since many decisions are made on such grouping. Whether or not more granular grouping of pages into "applications" is needed remains to be seen (implementation experiment?)</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Furthermore, consider performance going forward. CPUs have pretty much<br>
gotten as fast as they're getting -- all further progress is going to be<br>
in making multithreaded applications that use as many CPUs as possible. We<br>
should actively moving away from single-threaded designs towards<br>
multithreaded designs. A shared global script is firmly in the old way of<br>
doing things, and won't scale going forward.<br>
<div class="im"></div></blockquote><div><br></div><div>Indeed, this proposal has nothing to do with promoting some sort of parallel computations or multi-threading. I'm also not convinced everything which is not multi-threaded is firmly the old way :-) As a member of the team that brought some features to WebKit workers, made workers work in Chrome and is bringing Shared workers to both, I surely can sympathize with looking at multi-threading as a proverbial hammer :-) but it doesn't look like everything can be done with it.</div>
<div><br></div><div> > Chat application opens separate window for each conversation. Any opened</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> window may be closed and user expectation is that remaining windows<br>
> continue to work fine. Loading essentially whole chat application and<br>
> maintaining data structures (roster) in each window takes a lot of<br>
> resources and cpu.<br>
<br>
</div>Use a shared worker.<br>
<br>
I know that some consider the asynchronous interaction with workers to be<br>
a blocker problem, but I don't really understand why. We already have to<br>
have asynchronous communication with the server, which holds the roster<br>
data structure, and so on. What difference does it make if instead of<br>
talking to the server, you talk to a worker?</blockquote><div><br></div><div>Global Script is more of the 'shared library' then a 'server' Again, academically there is no difference. Practically, there is. For example, UI frameworks, like Closure, can be shared across pages - multiple and well as successive, as in navigation from one to another. By not sharing them today, we make ever-faster JS engines to run ever-growing amounts of JS, spending memory, battery power and increasing latencies. It is not practical to share a UI framework in a worker because there are too many of event handlers and bound UI elements that are directly updated by such frameworks. Instead, sharing a library in a global script makes it possible to reduce the amount of script loaded into a popup chat window from 0.5Mb to a few kb - that is too big win to pass. We have fast CPUs and gigabytes of ram though the shared libraries are still a good idea.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> In an email application, a user may want to open a separate "compose"<br>
> window for a new email, often after she started to "answer in place" but<br>
> realized she'd like to look up something else in the mailbox for the<br>
> answer. This could be an instantaneous operation if the whole html tree<br>
> and the compose editor script were shared.<br>
<br>
</div>This is possible without a shared global script -- it's possible now, in<br>
fact. Just open a window, and graft the DOM tree from the original window<br>
into the new window.</blockquote><div><br></div><div>that is what GMail is doing today - but you still have that "progress indicator" before the new compositing window foes live - and if you close the 'opener' window while it happens (too often that takes a long time), you likely loose the half-constructed message. So we sat with GMail guys and came up with Global Script idea. In fact, those 'tear-offs' are a paint point exactly because they effectively have to load/start the whole "GMail application" to become independent from the 'opener'.</div>
<div> </div><div>> Such multiple-window use cases could be simpler and use much less</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> resources if they had access to a shared Global Script Context so there<br>
> is no need to re-initialize and maintain the same state in all the<br>
> pages. Having direct, same-thread DOM/JS access to this context makes it<br>
> possible to avoid loading and initialization of repetitive code and<br>
> data, makes separate 'UI windows' simpler and independent.<br>
<br>
</div>There's no need for this case to use shared _global_ script; a shared<br>
script just between the original window and the popped-out window is<br>
sufficient (and already supported).</blockquote><div><br></div><div>Not sufficient - because of the artificial requirement to keep one of the windows open all the time - which is unnatural for the users who usually treat windows of the same site as 'peers'.</div>
<div><br></div><div>I do agree that experience of practical implementation would be very valuable here.</div><div><br></div><div>Dmitry</div><div>Dmitry</div></div>