[whatwg] Installed Apps

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