W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2009

[whatwg] Installed Apps

From: Ojan Vafai <ojan@chromium.org>
Date: Tue, 28 Jul 2009 18:04:56 -0400
Message-ID: <78dc8440907281504v4a0e694ft39d6d07606edb26d@mail.gmail.com>
On Tue, Jul 28, 2009 at 1:01 PM, Drew Wilson <atwilson at google.com> wrote:

> So (and forgive me for restating), it seems like hidden page addresses the
> following problems that gmail and other large web apps are having:
>
> 1) Loading large amounts of Javascript is slow, even from cache.
>
2) Loading application state from the database is slow.
>

Do we know why 1 and 2 are true? Can it be fixed?


> 3) Sharing between pages requires going through the database or shared
> worker - you can't just party on a big shared datastructure.
> 4) There's no way to do things like new mail notifications, calendar
> notifications, local updates of your email inbox, etc when the browser is
> not open. Currently, even the most brain-dead shareware desktop calendar app
> can display an event notification, while web-based calendars are forced to
> rely on the user remembering to keep a browser window open.
>
> Am I missing any other issues that hidden page is supposed to address?
>
> A persistent worker could address #4 (perhaps with some limitations on
> network access to address security concerns). For #1/#2/#3, are we saying
> that web applications *must* install themselves (with the requisite user
> flow) just to get fast load times? That seems unfortunate - if I don't care
> about #4, I'd really like to be able to get the benefits of #1/2/3 without
> jumping through a user install.
>

Yes, but a background page keeps a lot of state in memory semi-permanently.
It's not acceptable for any web page to have the power to use significant
system resources even after it's been closed.

The most contentious part of this proposal is keeping the page open after
all it's parent pages have been closed. #3 only needs background pages to be
open as long as it's parent pages are open. #4 can be somewhat solved by
this, but there are other less resource intensive solutions to that as well.

Something like Aaron's proposal where "the lifetime of the page could be
refcounted by pages referencing it" seems reasonable though. It doesn't
solve the initial startup problem, but it does solve #3, which would allow
for making things like popping out an email to it's own window fast.

In addition, putting this behind an install UI like extensions seems fine to
fix the startup case and #4, although I agree that you shouldn't need to
"install gmail" for it to load quickly.

I'd like to understand the underlying reasons for #1 and #2. As Jonas said,
there may be alternative solutions that are less prone to abuse of system
resources. For example is loading cached JS so slow because it needs to hit
disk? That could be solved by an AppCache extension that pins resources in
memory if possible.

Ojan

-atw
>
>
> On Mon, Jul 27, 2009 at 6:39 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> On Jul 27, 2009, at 7:13 PM, Aryeh Gregor wrote:
>>
>>  I'm not clear how the UI requirements here are different from
>>> persistent workers, though.  Those also persist after the user
>>> navigates away, right?
>>>
>>
>> Persistent workers are even more of a security risk, since they are
>> supposed to persist even after the browser has been restarted, or after the
>> system has been rebooted. Persistent workers should be renamed to "BotNet
>> Construction Kit".
>>
>> Regards,
>> Maciej
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090728/991d7aca/attachment.htm>
Received on Tuesday, 28 July 2009 15:04:56 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:14 UTC