[whatwg] Global Script proposal.

Another thing: 
 
>From the proposal it seems it will be possible for the GlobalScript context
to keep references to objects (DOM, JS data, etc) private to pages, and vice
versa possible for pages to keep references to GlobalScript objects. This
also opens up for a new way for independent pages finding and keeping
references to each other's objects if they are somehow registered in the
GlobalScript. 
 
When reloading a page there is also the additional dimension of the
GlobalScript possibly holding references to objects both from the previous
and current incarnation of the Document. In a way it seems GlobalScript
usage will in practice merge the JS worlds of all participating pages,
potentially including those already navigated away from.
 
What are your thoughts on this?
 
Best regards
Mike


  _____  

From: whatwg-bounces@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/20090821/c04dfe11/attachment-0001.htm>

Received on Friday, 21 August 2009 04:50:18 UTC