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