[whatwg] Installed Apps

[Drew Wilson]

I've been kicking around some ideas in this area. One thing you could do
with persistent workers is restrict network access to the domain of that
worker if you were concerned about botnets. That doesn't address the "I
installed something in my browser and now it's constantly sucking up my CPU"
issue, but that makes us no different than Flash :-P
Anyhow, addressing some of the other comments - I don't think that there's
necessarily a problem with the async worker APIs as they stand, and I don't
think we can easily retrofit synchronous APIs on top of their current
execution model. The issue is that the core problem that Workers solve
(parallel execution in a separate context from the page) is different than
the problem that large web apps are trying to address (reduced latency).

SharedWorkers are overloaded to provide a way for pages under the same
domain to share state, but this seems like an orthogonal goal to "parallel
execution" and I suspect that we may have ended up with a cleaner solution
had we decided to address the "shared state" issue via a separate mechanism.

Similarly, the "hidden page" mechanism seems to address a bunch of issues at
once, and I'm wondering if we explicitly laid out the problems it's trying
to solve, whether we might find a set of distinct smaller solutions that
were more generally applicable. I just don't want to make the same design
choices that we did with SharedWorkers, and end up with a monolithic
solution that doesn't address the individual goals (i.e. cross-page sharing)
in a developer-friendly manner.

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

-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/6b1d69b0/attachment-0001.htm>