[whatwg] Installed Apps

[Michael Davidson]

Hello folks -

I'm an engineer on the Gmail team. We've been working on a prototype
with the Chrome team to make the Gmail experience better. We thought
we'd throw out our ideas to the list to get some feedback.

THE PROBLEM

We would like to enable rich internet applications to achieve feature
parity with desktop applications. I will use Gmail and Outlook as
examples for stating the problems we hope to solve.

-- Slow startup: When a user navigates to mail.google.com, multiple
server requests are required to render the page. The Javascript is
cacheable, but personal data (e.g. the list of emails to show) is not.
New releases of Gmail that require JS downloads are even slower to
load.
-- Native apps like Outlook can (and do) run background processes on
the user's machine to make sure that data is always up-to-date.
-- Notifications: Likewise, Outlook can notify users (via a background
process) when new mail comes in even if it's not running.

A SOLUTION

Our proposed solution has two parts. The first, which should be
generally useful, is the ability to have a hidden HTML/JS page running
in the background that can access the DOM of visible windows. This
page should be accessible from windows that the user navigates to. We
call this background Javascript window a "shared context" or a
"background page". This will enable multiple instances of a web app
(e.g. tearoff windows in Gmail) to cleanly access the same user state
no matter which windows are open.

Additionally, we'd like this background page to continue to run after
the user has navigated away from the site, and preferably after the
user has closed the browser. This will enable us to keep client-side
data up-to-date on the user's machine. It will also enable us to
download JS in advance. When the user navigates to a web app, all the
background page has to do is draw the DOM in the visible window. This
should significantly speed up app startup. Additionally, when
something happens that requires notification, the background page can
launch a visible page with a notification (or use other rich APIs for
showing notifications).

WHY NOT SHARED WORKERS

Shared workers and persistent workers are designed to solve similar
problems, but don't meet our needs. The key difference between what
we're proposing and earlier proposals for persistent workers is that
background pages would be able to launch visible windows and have full
DOM access.  This is different from the model of workers where all
interaction with the DOM has to be done through asynchronous message
passing. We would like background pages to be able to drive UI in a
visible window using the techniques (DOM manipulation, innerHTML) that
are common today. We believe that more apps would be able to take
advantage of a background page if they didn't require rewriting the
app in the asynchronous, message-passing style required by workers.
Allowing the background page to drive the UI by doing direct DOM
manipulation is a more common programming style. For apps that don't
need the benefits of multiple threads provided by shared workers, this
will give the benefits of fast startup and the benefits of running in
the background (like showing notifications) without the downside of
the worker programming model.

The concepts here are similar to permanent workers, but with a
different programming model.

IMPLEMENTATION AVENUES

For now, we have a simple API in Chrome. This is meant as a prototype
of the concepts, not as a final API.

-- installApp(uri, name) Fetches the HTML page at uri, and runs it as
a hidden window. Currently this window is loaded when the machine
starts. This should eventually involve permissioning UI, but this is
not implemented. name is a name that can be used to get access to the
hidden window.
-- getInstalledApp(name) Returns a reference to the background page,
or null if the app is not installed.
-- removeInstalledApp(name) The moral equivalent of window.close() for
a background page.

We might migrate to a model where webapps can be installed as Chrome
extensions instead of using a Javascript call to install the app.

Another alternative we've discussed is allowing authors to specify in
their AppCache manifest that a given page should be an always-loaded
background page. This seems like a natural fit since the AppCache
manifest is where authors describe the attributes of various parts of
their app.

KNOWN ISSUES

As mentioned in earlier discussions about persistent workers,
permissioning UI is a major issue.

FEEDBACK

We would like to know if others would find this functionality useful.
Does anyone have an idea for a better API?


Michael