Plugin Infrastructure Plans

[Ryan Riley]

I'm taking this question here from the IOC discussion. What's the plan for the plugin infrastructure? I know the plugin infrastructure is planned for 2.1 and 2.0 is still on its way out, but I thought I would get the conversation started, as I think the codec nesting might play into this as well. I've not developed a plugin infrastructure before, so I'm also curious how to approach it.

So for starters, these are the questions that spring to mind:

• Are MAF and/or MEF in consideration? (They don't need to be; I'm just curious.)
• Are plugins and "modules" synonymous?
• In other words, do plugins extend OR directly [1], add to the configuration [2], or both?
• I think you mean [1], but I just wanted to check.
• Also, if we aren't talking about [2] 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.
• 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 [1] 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?

I'm not really looking for immediate answers, just trying to start the discussion. Seb, if I'm jumping the gun, please shoot me down and tell me to hold up a bit. I'm really excited about this part (as well as the codec nesting) and trying hard to get some time freed up to focus more on helping out.

[1] In AtomSite, the core is very specifically a platform for hosting plugins/modules that run the application. Even the blog feature--the primary feature--is a plugin.

[2] The Prism project uses a modular structure to compose applications of WPF together. Here, OR would equate to WPF and plugins would equate to modules.

Regards,

Ryan Riley

Email: ryan....@panesofglass.org
LinkedIn: http://www.linkedin.com/in/ryanriley
Blog: http://wizardsofsmart.net/
Website: http://panesofglass.org/

[Sebastien Lambla]

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?

Yes

o    In other words, do plugins extend OR directly [1], add to the configuration [2], or both?

Both.

o    I think you mean [1], but I just wanted to check.

o    Also, if we aren't talking about [2] 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 [1] for better understanding of what I'm getting at here.)

Yes

·         What are plans for sharing plugins / hosting a plugin repository on the OpenRasta.com site?

The same

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 :)

 

Seb

 

[Ryan Riley]

Three thoughts I need to elaborate on further:

1. MEF will now be part of Mono, according to Glenn Block's latest presentations. Does that solve any issues there? (I am not trying to sell MEF, but it might still be worth evaluating.)
2. I saw you on the Horn list; are you looking at Horn as a possible package repo?
3. Jeffrey Palermo's recent post on using MVC Portable Areas within WebForms was quite interesting. Would this be something we could abstract a bit further and allow within OR so that PAs written in either MVC or OR could work across even more platforms?

I really appreciate and liked a lot of your points above. I think you covered all the things I was thinking of, and I fully agree with your final point.

Cheers!

Ryan Riley

Email: ryan....@panesofglass.org
LinkedIn: http://www.linkedin.com/in/ryanriley
Blog: http://wizardsofsmart.net/
Website: http://panesofglass.org/