[whatwg] Installed Apps

[Sebastian Markbåge]

>
> 2) For multi-process browsers like Chrome, there seem to be limitations as
> to what can actually be accessed between processes (direct DOM access across
> process boundaries seems problematic for example). Do you have ideas about
> how to address this, since assumedly the page calling getInstalledApp()
> could be running under some arbitrary process?


Even with single-process browsers you would have to handle threading issues
in a way that is just not done in all browsers yet.

For a) - Having some way to load large amounts of cached javascript quickly
> in a new page seems like an issue that would be nice to address in general,
> not just for pages that install hidden pages. Are there other approaches
> worth trying here?


Loading of cached JavaScript isn't really that slow. I think the real issue
here is client state. It's often a good idea to have a copy of running
scripts in each process for stability anyway. However, cached
parsing/pre-compilation (if available) of scripts might be a generally good
idea. Perhaps some kind of process cloning like *nix forks?

IMHO, this could be solved cleaner and more memory efficient way with some
form of persistent workers rather than a "hidden" page. But I might be
missing something.

On Tue, Jul 28, 2009 at 1:30 AM, Drew Wilson <atwilson at google.com> wrote:

> This sounds really powerful, and seems like a natural evolution of some of
> the stuff we've discussed previously for persistent workers. A few
> comments/notes:
> 1) It sounds like this background page would act like any other web page
> with respect to its processing model (i.e. like other pages, script running
> in this page would be limited as to how long it can run, as opposed to
> workers which can run for any arbitrary length of time). This seems
> reasonable, especially since this page could assumedly still create workers
> if it need to do true background processing. It's really more of a "hidden"
> page than a "background page"?
>
> 2) For multi-process browsers like Chrome, there seem to be limitations as
> to what can actually be accessed between processes (direct DOM access across
> process boundaries seems problematic for example). Do you have ideas about
> how to address this, since assumedly the page calling getInstalledApp()
> could be running under some arbitrary process?
>
> 3) This approach has another advantage over something like workers in that
> a hidden page can do cross-domain access/sharing via iframes, whereas
> workers don't really have any facility for cross-domain access.
>
> 4) I had a quick question/clarification about the motivation behind this -
> aside from the advantages described above, it sounds like the specific
> problem you are solving by a hidden page is a) you don't have to load
> javascript in a new page (which I'm assuming must be slow), and b) you don't
> have to load client state in the new page.
>
> For a) - Having some way to load large amounts of cached javascript quickly
> in a new page seems like an issue that would be nice to address in general,
> not just for pages that install hidden pages. Are there other approaches
> worth trying here?
>
> For b) - How much client state are we talking about? If you were to pursue
> this approach using workers to maintain client state, how much data would
> you expect to be transferred to the client app on startup? We're seeing
> fairly low latency for client<->worker communication, so in theory it
> shouldn't be a huge source of slowdown.
>
> I agree that the programming model of the hidden page is much cleaner/more
> familiar than rewriting applications to use asynchronous messaging, so that
> may be sufficient motivation for this.
>
> -atw
>
>
> On Mon, Jul 27, 2009 at 11:50 AM, Michael Davidson <mpd at google.com> wrote:
>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090728/17aa2e04/attachment-0001.htm>