<br><br><div class="gmail_quote">On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson <span dir="ltr"><<a href="mailto:mikewse@hotmail.com">mikewse@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This is an interesting suggestion as it isolates the<br>
stateful parts from the rest of the previous suggestions.<br>
I like state.<br>
<br>
Here's how I see how it fits inside the big picture:<br>
<br>
Scope Serialized state Live state<br>
----- ---------------- ----------<br>
user agent WS_localStorage, GlobalScript [2]<br>
SharedWorker [1]<br>
cookie<br>
<br>
browsing context WS_sessionStorage - [3]<br>
<a href="http://window.name" target="_blank">window.name</a><br>
<br>
document - plain JS objs [4]<br>
<br>
history entry History.pushState plain JS objs [4]<br>
<br>
[1] Global state can be coordinated by a SharedWorker but<br>
it would need to be serialized in postMessage on transfer<br>
so that's why I've put it in the "serialized" column.<br>
<br>
[2] As I understand it, the new GlobalScript construct is<br>
a context that can be shared by all browsing contexts in<br>
the user agent.<br>
<br>
[3] You also mention that the feature could be usable for<br>
page-to-page navigation within the same browsing context.<br>
It hasn't been suggested yet, but it would be possible to<br>
have a variation of GlobalScript that binds to a specific<br>
browsing context, analogous to sessionStorage.<br>
<br>
[4] These plain JavaScript objects indeed live throughout<br>
their Document's life, but this lifetime is usually<br>
shorter than what the user's perception tells him. Ie,<br>
when the user returns to a previous page through the Back<br>
button he regards that as the "same" document, while<br>
technically it's usually a "new" Document, with a freshly<br>
created document tree and JavaScript context.<br>
<br>
Questions<br>
---------<br>
<br>
Threading:<br>
This is the unavoidable question ;-) How do you envision<br>
multiple threads accessing this shared context to be<br>
coordinated?<br></blockquote><div><br></div><div>Nominally, they don't. In our design for chrome's multi-process architecture, the global-script would only be shared within a single 'renderer' process (in which all page's, and global-scripts, execute in a single thread).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Process boundaries:<br>
In this past discussion there have been several mentions<br>
about having to cluster "pages" inside the same process<br>
if they are to share data.<br>
Why is this so, and why can't shared memory or proxied<br>
objects be an option for browsers doing process<br>
separation?<br>
<br></blockquote><div><br></div><div>A multi-process browser vendor probably *could* proxy all script calls to a truely global context across all 'renderers'... but that is not required in the proposal... and is probably even discouraged.</div>
<div><br></div><div>One of the motivations for doing this is webapp performance. Proxying all script interactions across the page/context boundary works against that. Also synchronization issues get much more complicated.</div>
<div><br></div><div>Implicit in the proposal is that a global-script is very inexpensive to interact with.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Best regards<br>
Mike Wilson<br>
<br>
<br>
________________________________<br>
<br>
From: <a href="mailto:whatwg-bounces@lists.whatwg.org">whatwg-bounces@lists.whatwg.org</a><br>
[mailto:<a href="mailto:whatwg-bounces@lists.whatwg.org">whatwg-bounces@lists.whatwg.org</a>] On Behalf Of Dmitry Titov<br>
Sent: den 17 augusti 2009 23:38<br>
To: <a href="mailto:whatwg@whatwg.org">whatwg@whatwg.org</a><br>
Subject: [whatwg] Global Script proposal.<br>
<div><div></div><div class="h5"><br>
<br>
Dear whatwg,<br>
<br>
The previous discussion about shared page and persistence has sent<br>
us back 'to the drawing board', to think again what is the essence of the<br>
feature and what's not important. Talking with web apps developers indicates<br>
the most of benefits can be achieved without dangerous background<br>
persistence or the difficulty to specify visual aspects of the invisible<br>
page.<br>
<br>
Here is the new proposal. Your feedback is very appreciated. We are<br>
thinking about feasibility of doing experimental implementation in<br>
WebKit/Chrome. Thanks!<br>
<br>
-----<br>
<br>
SUMMARY<br>
<br>
Currently there is no mechanism to directly share DOM, code and data<br>
on the same ui thread across several pages of the web application.<br>
Multi-page applications and the sites that navigate from page to page would<br>
benefit from having access to a shared "global script context" (naming?)<br>
with direct synchronous script access and ability to manipulate DOM. This<br>
would compliment "Shared Workers"<br>
(<a href="http://www.whatwg.org/specs/web-workers/current-work/" target="_blank">http://www.whatwg.org/specs/web-workers/current-work/</a>) by providing a<br>
shared script-based context which does not run on a separate thread and can<br>
be used directly from the application's pages.<br>
<br>
USE CASES<br>
<br>
Chat application opens separate window for each conversation. Any<br>
opened 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 resources<br>
and cpu.<br>
<br>
Finance site could open multiple windows to show information about<br>
particular stocks. At the same time, each page often includes data-bound UI<br>
components reflecting real-time market data, breaking news etc. It is very<br>
natural to have a shared context which can be directly accessed by UI on<br>
those pages, so only one set of info is maintained.<br>
<br>
A game may open multiple windows sharing the same model to provide<br>
different views at the game objects (as in flight simulator).<br>
<br>
In an email application, a user may want to open a separate<br>
"compose" window for a new email, often after she started to "answer in<br>
place" but realized she'd like to look up something else in the mailbox for<br>
the answer. This could be an instantaneous operation if the whole html tree<br>
and the compose editor script were shared.<br>
<br>
Such multiple-window use cases could be simpler and use much less<br>
resources if they had access to a shared Global Script Context so there is<br>
no need to re-initialize and maintain the same state in all the pages.<br>
Having direct, same-thread DOM/JS access to this context makes it possible<br>
to avoid loading and initialization of repetitive code and data, makes<br>
separate 'UI windows' simpler and independent.<br>
<br>
Another case is an application that uses navigation from page to<br>
page using menu or some site navigation mechanism. Global Script Context<br>
could keep the application state so it doesn't have to be round-tripped via<br>
server in a cookie or URL. For example, wizard-like file upload web<br>
application could be implemented as a simple sequence of static pages<br>
connecting to the local Global Script. It also makes browser's history<br>
feature 'just work' so there is no need for complicated history managers<br>
like this: <a href="http://developer.yahoo.com/yui/history/" target="_blank">http://developer.yahoo.com/yui/history/</a>. Note that Global Script<br>
should be able to live through a page-to-page navigation for this to work<br>
well.<br>
<br>
Yet another use case is provided by JS frameworks like SproutCore<br>
(<a href="http://wiki.sproutcore.com/Basics-Introducing+SproutCore+MVC" target="_blank">http://wiki.sproutcore.com/Basics-Introducing+SproutCore+MVC</a>) which try to<br>
bring to the Web the traditional Model-View-Controller model which is based<br>
around having a single data model which can be bound to various 'views'. The<br>
binding usually happens via Controller that keeps specific mapping between<br>
the application's data structure and the structures needed to support UI<br>
views. Controller is also the one responding to UI events and figuring out<br>
what change should be applied to the model. This means that controller is<br>
best shared across 'UI pages' and run on the same thread. The Model part<br>
could be implemented in a Global Script or as a Shared Worker though.<br>
<br>
WORKAROUNDS<br>
<br>
HTML5 provides several mechanisms that can be used to workaround the<br>
absence of Global Script. The Application Cache may be used to avoid server<br>
roundtrips for megabyte-sized JS libraries. Local Storage may help to pass<br>
data from one page to another. Shared Workers seem like a great place to put<br>
a shared server connection for a chat application. However, even loading JS<br>
library from the local cache takes time, which makes sub-100ms typical UI<br>
response times difficult to achieve sometimes and increases memory<br>
footprint. Storing transient application data in local storage requires<br>
serialization of it and is difficult for some types of data (like a current<br>
selection in a document). Shared Workers are actually separate threads and<br>
it's impossible to directly call JS in them or make them operate on DOM or<br>
receive input events.<br>
<br>
As a workaround, today many sites try to maintain a single "main<br>
page" and avoid navigating from it. This page provides a shared context,<br>
while 'UI panels' are built into that page as iframes or generated<br>
dynamically. Many applications use dynamic content creation to simulate<br>
'page navigation' (as in Facebook). To support back-forward history in<br>
browser they use fragment URLs which requires more client-side code, extra<br>
network request (for example, when navigating to a bookmark) and are not<br>
reliable (may loose history on refresh for example). Because of the<br>
additional code required to 'wrap' almost every regular browser feature like<br>
refresh or a click on a link, these solutions tend to be buggy. Hotmail.com<br>
viewed in Safari is a vivid example of it.<br>
<br>
PROPOSAL<br>
<br>
A web page will be able to create a Global Script and connect to it,<br>
as in this example:<br>
<br>
var context = new GlobalScript(); // perhaps 'webkitGlobalScript'<br>
as experimental feature?<br>
context.onload = function () {...}<br>
context.onerror = function () {...}<br>
context.load('foo.js');<br>
<br>
All pages connected to the same Global Script should run on the same<br>
thread, in the same process. Since this is not always technically possible,<br>
it should be legal (and not break the applications) for there to be<br>
duplicate global script contexts within a UA. For example, in a<br>
multi-process browser, two pages cannot share a context if they're loaded<br>
in separate processes. That said, there are many heuristics that UAs could<br>
use to alleviate this problem. For example, if one page uses a global<br>
script, subsequent pages from the same origin could be loaded in that same<br>
process. It is possible to structure the web application in a way to take<br>
advantage of the shared Global Script.<br>
<br>
The Global Script is terminated soon after last page that is<br>
connected to it closes (just like Shared Workers). A UA should use<br>
navigation's target url to keep Global Script alive across navigations from<br>
page to page of the same application.<br>
<br>
The return value from a constructor is the Global Script's "global<br>
scope object". It can be used to directly access functions and variables<br>
defined in global scope of the Global Script. While this global scope does<br>
not have 'window' or 'document' and does not have visual page associated<br>
with it, the local storage, database, timers and XHR are exposed to it, and<br>
it can build up DOM for the connected pages using their 'document' object.<br>
The list of interfaces exposed in the global scope of the Global Script is<br>
similar to that of Shared Worker, except message-passing interface. It could<br>
also include events fired when a page connects/disconnects to it and before<br>
it is terminated.<br>
<br>
For security reasons, the Global Script falls under the limits of<br>
the same origin policy.<br>
<br>
Using Global Script is better for certain tasks then using Shared<br>
Worker since it is not necessary to serialize or deal with concurrency, and<br>
it can access DOM directly.<br>
<br>
<br>
<br>
</div></div></blockquote></div><br>