Chrome Gets Plugins: How to Write a Chrome Extension in Three Easy Steps
mattcutts.com
mattcutts.com
My simplified definition: plugins run native code, extensions run Javascript. Flash if a plugin, Firebug in an extension.
Don't expect actual extensibility from Chromium any time soon. If they can't be bothered to even plan for platform independence (http://dev.chromium.org/developers/browser-bootstrapping) then they don't have the design wherewithall to retrofit a C++ app with a comprehensive extension mechanism.
My hope is that a Google-independent fork will start that extracts the nifty subsystems in Chromium, like process level isolation, and uses them to build a more thoughtfully architected browser/platform.
2) Since Chrome relies heavily on process isolation, I would think that a lot of the architecture of the browser is tied to the platform. Even the html rendering pipeline (based on WebKit) runs out-of-band and the rendered bitmap is send to the browser window via IPC. (I don't work on the team but from my understanding of someone's comments, this is how it roughly works)
3) Regarding extensibility, I agree that I doubt Google is going to provide much extensibility of the actual browser chrome. Google's interests are in the web sites themselves and as such, the greasemonkey-like extensions are what they're probably going to promote. They want to hide the browser container as much as possible and move the focus to the web page inside it.
3) If Chrome is to be a platform, it's going to need a shell with a rich interface to manage multiple applications and allow them to interact with each other. It's also going to need an ecosystem and the people it needs in that ecosystem use OSX and Linux. Making it inflexible or "hiding" it are the exact wrong things to do.
Firefox Greasemonkey scripts are used by power users to make minor tweaks to specific sites. I don't see how that functionality will further Google's lofty plans for Chrome. This was a quick hack that nominatively fulfilled a very popular feature request.
I'm certainly not the one in charge of directing Google's vision but it would seem to logical to me that they are not interested in creating a new 'platform' in the sense that xul is a platform. As far as I can see, the purpose of Chrome is to promote web apps as a reasonable alternative to desktop apps.
I can imagine AdBlock, as well as other plugins that deal mainly with the DOM, as entirely possible. I mean, how much does AdBlock really do? Grabs a list of blacklisted URLs (with wildcards), matches applicable elements in the DOM, and removes them.
AdBlock may prevent these requests from being issued at all, but that isn't to say you can't implement something similar in a Greasemonkey-like environment.
To top it all off, from an ad-provider's perspective, why should I be paying for ad impressions that the end user doesn't even get to see? At least with Adblock, my server bandwidth isn't used, and my impression statistics aren't being impacted by users who aren't actually getting the chance to view the content...
But now I'm way out into conjectureland. Just thinking out loud here.
Hopefully chrome moves in this direction. I realize that it's a really hard thing to get right, especially in a browser.
http://dev.chromium.org/developers/design-documents/extensio...
I'd expect announcements in May:
However, XUL and Javascript is a very heavy-weight way of doing things. Chrome and other browsers have a native UI. That is partially what makes Chrome a light-weight browser. It also means that the deep level of cross platform add-on's available for Firefox will not be possible for Chrome in it's current state.
I've read the proposals for expanding Chrome extensions and it sounds like they want to go a similar route to XUL. It probably won't be as low-level because they'll want to keep their native UI code. That will help Chrome to provide some more complex plugins with their own UI but still won't allow for some of the more radical and interesting plugins available for Firefox.
Check out the editor of XBL - for those not familiar, XBL is what XUL is built on top of as well as all the widgets you see in the mozilla platform (ff/tb etc), including all your html controls. I think if google went this route, they are definitely picking up where netscape left off and where moz foundation has limped along with, ie. building a platform around the browser.
When complete, the ID is going to be a hash of the extension's public key, and extension content will be signed with the key. So there won't be conflicts (unless you share your private key).
Note: i'm being sarcastic