[whatwg] Installed Apps

[Michael Nordman]

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
>
>