Interesting thoughts. This is sounding more like Android's "services" (long-running background tasks) and "activities" (apps run in response to a user action) model.
One thought I had in response to this is, who would display the UI? We'd be able to do something primitive in the browser, like static button + text, but for more complicated things, we'd want an HTML renderer. On Mon, Feb 23, 2009 at 11:20 AM, Aaron Boodman <[email protected]> wrote: > > The other day I mentioned off-hand in a hallway conversation that I > thought it should be a goal for the extensions system in Chrome to > significantly increase the average number of extensions installed per > user, and to happily support up to 20 or 30 extensions installed at > once (both visually and technically). > > It occurred to me that our current thoughts for how extensions are > built may not be the best match for this kind of scalability. > > For example, we have said that extensions will have a background > context that has the same lifetime as the browser process. Such a > background context is useful for many types of extensions, but there > are probably just as many that don't need it. For example, there are > probably lots of "tool" use cases that only really need to run code > after a button is clicked in the toolbar. > > Similar thoughts around user scripts. Sure it's useful to run code on > page load, but there are lots of use cases that don't require that. > They only need to inject code into the page when a button is clicked. > > Another interesting related thought is that an extension which runs > code only in response to declared UI is "safer" than an extension > which automatically runs code for every page, or runs code > persistently in the background. > > This all led me to the conclusion that background contexts and user > script injection should be options, but not the default way to get > things done. Many extensions can be accomplished with some declarative > UI, and then some code which will be run when the UI is used. No > extension code needs to be run until the user actually chooses to use > the extension. As soon as the code is complete the execution > environment can be torn down. > > Extension processes can be created as necessary to support calls from > user scripts, or to display HTML UI, but then could go away once they > aren't needed anymore. > > Running background processes and running user scripts automatically > could event be a permission that an extension declares that it wants > to do and is presented to the user on installation. > > Thoughts? > > - a > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
