Yo. Lots of questions :)
∑ Are MAF and/or MEF in consideration? (They don't need to be; I'm just curious.)
Nope. MAF because we donít need addins, MEF because itís a delay loaded container that would only solve binary dependency issues. Plus I donít want to introduce dependencies on too many components that wouldnít run across a wide range of platforms :)
∑ Are plugins and "modules" synonymous?
o In other words, do plugins extend OR directly , add to the configuration , or both?
o I think you mean , but I just wanted to check.
o Also, if we aren't talking about  here, how is the composite story addressed by OR? I remember you commenting in the E-VAN that the fluent configuration was only one way of structuring an OR application, but it's the only one I've seen to date.
Thatís why we have the configuration metamodel in place. The fluent API is just a wrapper on top of that.
∑ Will the plugin infrastructure change the structure of the project to move some of the projects into plugins instead of compiled into the OR library? (Again, see  for better understanding of what I'm getting at here.)
∑ What are plans for sharing plugins / hosting a plugin repository on the OpenRasta.com site?
Now, to be a bit less cryptic. Letís review a few of the core scenarios that I want to solve.
∑ I want to add castle, sparkview, fluent nhibernate or other dependencies to my site
o I need to download packages, compile them or get them from a site or however I decide to get binaries sorted.
o I then need to add references to the project
o Then I need to add the configuration code somewhere to start using those features
∑ I want to separate a web application in multiple modules that can be built and compiled independently, say a newsgroups system
o I need to download an application, maybe an msi, maybe some code
o I then need to create a virtual app in IIS, or whatever else, copy all the files
o I then need some extra work to integrate my existing app with the new one, with a whole bunch of lovely things after that
∑ I want to deploy part or all of my web app
o I create an IIS app, add FTP, copy the files through FTP
o Or I create an IIS app, I use msdeploy to synchronize the files.
o Or I remote desktop to the machine, I install an msi because itís a windows service weíre deploying
o Etc etc etc.
If you look at every single of those problems globally, you start seeing a pattern:
∑ Existing frameworks are comprised mostly of dlls, maybe some config files and some other loose bits here and there. Theyíre currently packaged in msi, zip or whatever is convenient. Web applications are absolutely no different, as they contain some content files, some dlls, maybe some config files.
∑ You roughly do three thinks with those packages: you build them, you consume them or you deploy them.
The whole idea of the plugin system is to provide a package that can be dynamically deployed in your dev environment (and update your msbuild projects accordingly, adding references as needed) or to your live environment (and automatically becomes part of the application upon restart).
Now that means indeed that your main website will not be the hosting environment anymore, but only one of the modules that already exist. You only have to deploy the hosting environment, and everything after that is a nice package of dependent packages. Brilliantly enough, that also means you can now build and deploy your system without thinking very much which environment its gonna run on, as this is a separate thing altogether.
Thereís a couple of existing things that exist that can give us a good idea of the direction to take. Horn does source code dependencies, but doesnít handle binaries. Gems has a great model but is not suited IMO for binary dependencies because of version dependencies. Java has a deployment model on their app servers that does something roughly equivalent, but doesnít support (as far as I understand it) the development-time stuff I want to see.
Sooo in concrete terms, this requires a bunch of things:
∑ A package model that lets you (for now) package files that exist as independent modules
∑ A package dependency model by which a package is compatible with a range of versions of another package
∑ A package repository system that should be based on http for simplicity, and should definitely be multi-homed
∑ An easy deployment model to setup the hosting environment that can receive the packages. MSDeploy and the platform installer of MS is ideal to create that hosting base on IIS, we would of course need to provide one for other hosting environments to let people just create and deploy a package to a windows service with the same ease theyíd expect from an IIS deployment
∑ A change in the default msbuild project to automatically include dependencies that suddenly appear in the local package repository for a project
∑ A package repository explorer to discover and download all the packages and copy them in the right location
∑ A secondary configuration filling mechanism that lets each package register itself to the system at run time
∑ And support for scoped configurations so you can support having various packages register their own uri space in their own subfolders
It is not as much work as it looks, but if done right itíll solve a *massive* amount of issues that make building a new project so awful atm.
Anyway, any comments / feedback at this stage would be great :)