- From: Michael Davidson <mpd@google.com>
- Date: Tue, 28 Jul 2009 21:24:12 -0700
Sorry for starting and then dropping out of the discussion for a few days. - I agree with everyone else that there are two parts to the proposal. The first, less controversial part is a shared context that lives inside of the browser. As Aaron points out, this is very similar to Chromium extensions, and shouldn't require user permission beyond that of extensions today. Extensions live as long as the browser, so whatever UI browsers use for extensions should be sufficient. On Tue, Jul 28, 2009 at 10:01 AM, Drew Wilson<atwilson at google.com> wrote: > 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. These are true, but leave out the part that rewriting large apps to the worker API is nontrivial. A major advantage of a hidden page (as you mention below) is that the programming model is well known, and easy for web developers to adapt to. If your app is big enough to need the advantage of a shared page, a user install doesn't seem too big a hoop to jump through. - As for persistence beyond browser lifetime, I understand the reticence. However, similar problems have been solved in the past. Flash asks the user for access to hardware like cameras. Surely being able to take pictures of users is as scary as running code after the browser has closed. For browsers that do have extensions, having the extension outlive the visible browser process doesn't seem like that great a leap in functionality. We could definitely live with same-domain restrictions in hidden pages if it would allay some concerns. Having some sort of desktop presence is important for parity with desktop apps. Perhaps the install UI could look and feel more like the UI for installing a native app? Michael
Received on Tuesday, 28 July 2009 21:24:12 UTC