The terms plugin, extension, add-on, widget, drop-in, applet, cram-thru, etc. have all historically been used interchangeably to mean little more than "lack of modular design".
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.
1) If they had planned for platform independence, they wouldn't have been able to release anything for a long time.
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.
1 & 2) I should hope that a company worth hundreds of millions of dollars and employing a vast army of the greatest programming minds in the world could take the time to wrap their platform specific code in an abstraction layer, a relatively minor task that is now practiced almost universally, or at least use some of the many mature cross-platform libraries available.
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.
> 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.
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.
If they'd done that, they wouldn't even be in beta yet, let alone out of it. Look at how long Netscape 6, let alone Firefox, took to materialize. Remember that most of the Chrome team are ex-Firefox-luminaries: these are not stupid people, and you probably use their other products all the time.
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.