- From: Michael Nordman <michaeln@google.com>
- Date: Mon, 3 Aug 2009 15:35:01 -0700
On Mon, Aug 3, 2009 at 2:37 PM, Mike Wilson<mikewse at hotmail.com> wrote: > 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. Yes... client/server model in the browser... good observation... and a good way to think about the direction I would like to see things go. Incidentally, that line of thinking is my motivation for the introduction of script-generated responses in this (HTML5) system design. > > ? ? ? ? ? ? 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 15:35:01 UTC