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