- From: Mike Wilson <mikewse@hotmail.com>
- Date: Mon, 3 Aug 2009 23:37:27 +0200
Michael Nordman wrote: > > On Mon, Aug 3, 2009 at 3:05 AM, Mike > Wilson<mikewse at hotmail.com> wrote: > > > > Assuming this shared state doesn't require a full > > JavaScript global context, and could do with some > > root object or collection, would it be possible to > > extend Web Storage to support this task? > > A big part of what the Gmail team is interested in sharing is quite a > lot of javascript (loaded, parsed, jit'd... ready to call functions). > Along with that, the app can maintian shared state as well, but a big > part of this feature request is sharing the code itself. In the > absence of JS languange changes (analogous to DLLs or SOs for JS), I > think this does call for a full JS context. Right, with your scenario, that makes use of all these new features in the same app, that could make sense. Still, it would be interesting to look at how each feature could be implemented on its own, to potentially lessen the overhead for apps that only use a single feature. These are the individual features discussed so far, I think (did I miss any?): - "preload" JavaScript code - share "live" data between multiple pages - background process with direct access to UI - background process that outlives browser process - background process that auto-starts with operating system - access to notification area I can easily imagine separate use of the first two items, and I think it would be great to address the data handling in a coherent way with other state handling. It would be nice to have finer-grained control over data handling than having to "pop" a new window to use its global context. Btw, another reflection is that this mail thread is about introducing a client/server model in the browser. Some mentions of complex code in the background page, f ex building the HTML for the visible window, make me think of traditional server-centric webapps, but inside the browser. I've made the below table to illustrate this, and I mean to point out similarities between traditional server-centric and the new background_page-centric webapps, and between client-centric and visible-centric webapps. Maybe this can inspire some new thoughts. Remote Background Visible server page page ------ ---------- ------- Current webapp designs: server- state centric logic (bugzilla) gen HTML -> render client- state -> state centric logic (gmail) gen/render HTML New "background page" client-centric designs: background- state -> state centric logic gen HTML -> render visible- state -> state -> state centric (logic) logic gen/render HTML mvh Mike
Received on Monday, 3 August 2009 14:37:27 UTC