[whatwg] Installed Apps
Michael Nordman
michaeln at google.com
Mon Aug 3 15:35:01 PDT 2009
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
>
>
More information about the whatwg
mailing list