[whatwg] Installed Apps

[Mike Wilson]

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