<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3395" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=826292906-21082009><FONT face=Verdana 
color=#0000ff size=2>Another thing: </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=826292906-21082009><FONT face=Verdana 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=826292906-21082009><FONT face=Verdana 
color=#0000ff size=2>From the proposal it seems it will be possible for the 
GlobalScript context to&nbsp;keep references to objects (DOM, JS data, etc) 
private to pages, and vice versa possible for pages to keep references to 
GlobalScript objects. </FONT></SPAN><SPAN class=826292906-21082009><FONT 
face=Verdana color=#0000ff size=2>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. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=826292906-21082009><FONT face=Verdana 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=826292906-21082009><FONT face=Verdana 
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=826292906-21082009><FONT face=Verdana 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=826292906-21082009><FONT face=Verdana 
color=#0000ff size=2>What are your thoughts on this?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=826292906-21082009><FONT face=Verdana 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=826292906-21082009><FONT face=Verdana 
color=#0000ff size=2>Best regards</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=826292906-21082009><FONT face=Verdana 
color=#0000ff size=2>Mike</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> whatwg-bounces@lists.whatwg.org 
  [mailto:whatwg-bounces@lists.whatwg.org] <B>On Behalf Of </B>Dmitry 
  Titov<BR><B>Sent:</B> den 17 augusti 2009 23:38<BR><B>To:</B> 
  whatwg@whatwg.org<BR><B>Subject:</B> [whatwg] Global Script 
  proposal.<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>Dear whatwg,</DIV>
  <DIV><BR></DIV>
  <DIV>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&nbsp;dangerous background persistence or 
  the difficulty to specify visual aspects of the invisible page.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Here is the new proposal. Your feedback is very appreciated. We are 
  thinking about feasibility of doing experimental implementation in 
  WebKit/Chrome. Thanks!</DIV>
  <DIV><BR></DIV>
  <DIV>-----</DIV>
  <DIV><BR></DIV>
  <DIV>SUMMARY</DIV>
  <DIV><BR></DIV>
  <DIV>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" (<A 
  href="http://www.whatwg.org/specs/web-workers/current-work/">http://wwwwhatwg.org/specs/web-workers/current-work/</A>) 
  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.</DIV>
  <DIV><BR></DIV>
  <DIV>USE CASES</DIV>
  <DIV><BR></DIV>
  <DIV>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.</DIV>
  <DIV><BR></DIV>
  <DIV>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.</DIV>
  <DIV><BR></DIV>
  <DIV>A game may open multiple windows sharing the same model to provide 
  different views at the game objects (as in flight simulator).</DIV>
  <DIV><BR></DIV>
  <DIV>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.</DIV>
  <DIV><BR></DIV>
  <DIV>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.</DIV>
  <DIV><BR></DIV>
  <DIV>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: <A 
  href="http://developer.yahoo.com/yui/history/">http://developer.yahoo.com/yui/history/</A>. 
  Note that Global Script should be able to live through a page-to-page 
  navigation for this to work well.</DIV>
  <DIV><BR></DIV>
  <DIV>Yet another use case is provided by JS frameworks like SproutCore (<A 
  href="http://wiki.sproutcore.com/Basics-Introducing+SproutCore+MVC">http://wiki.sproutcore.com/Basics-Introducing+SproutCore+MVC</A>) 
  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.</DIV>
  <DIV><BR></DIV>
  <DIV>WORKAROUNDS</DIV>
  <DIV><BR></DIV>
  <DIV>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.</DIV>
  <DIV><BR></DIV>
  <DIV>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.</DIV>
  <DIV><BR></DIV>
  <DIV>PROPOSAL</DIV>
  <DIV><BR></DIV>
  <DIV>A web page will be able to create a Global Script and connect to it, as 
  in this example:</DIV>
  <DIV><BR></DIV>
  <DIV>var context = new GlobalScript(); &nbsp;// perhaps 'webkitGlobalScript' 
  as experimental feature?</DIV>
  <DIV>context.onload = function () {...}</DIV>
  <DIV>context.onerror = function () {...}</DIV>
  <DIV>context.load('foo.js');</DIV>
  <DIV><BR></DIV>
  <DIV>All pages connected to the same Global Script should run on the same 
  thread, in the same process. &nbsp;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. &nbsp;For example, in a 
  multi-process browser, &nbsp;two pages cannot share a context if they're 
  loaded in separate processes. &nbsp;That said, there are many heuristics that 
  UAs could use to alleviate this problem. &nbsp;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.</DIV>
  <DIV><BR></DIV>
  <DIV>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.</DIV>
  <DIV><BR></DIV>
  <DIV>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.</DIV>
  <DIV><BR></DIV>
  <DIV>For security reasons, the Global Script falls under the limits of the 
  same origin policy.&nbsp;</DIV>
  <DIV><BR></DIV>
  <DIV>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.&nbsp;</DIV>
  <DIV><BR></DIV></BLOCKQUOTE></BODY></HTML>