I spent a little bit of time this weekend playing around with IIS7's Hostable Web Core feature. This is a new thing in IIS7 that allows you to host IIS7 in a worker process of your own choosing. Kanwalijeet Singa has a nice description of the feature on his blog.

I love the idea of a having a lightweight, rehostable version of the IIS pipeline that can I stick anywhere. HostableWebCore is a great step in that direction, but (looking at things from a framework perspective, at least) it's not quite what I want.

Bring-your-own-process is nice, but I think I really want bring-your-own-app-domain as well. Having an appdomain barrier between the host and the pipeline is nice for reliability and enables things like AppDomain recycling, but I don't think I need that in all cases. I'd like to be able to new() up an IHttpHandler with some state in the host and stuff it in a Handlers collection and be done, without having to indirect though a local copy of applicationHost.config. I'd be willing to treat that pipeline configuration as immutable once opened in exchange for this capability.

I'd like to break the dependency on the physical file system as well, while we're at it. It would be nice if file system structure on disk were an option, not a requirement.

I wish the scope of HostableWebCore was at the virtual directory/application level instead of the site level. I'd love manage the HTTP.SYS URL reserverations externally instead of having HostableWebCore do it for me. This mainly so I can have multiple instances of this thing listening on the same port, demuxing by URL prefix at the HTTP.SYS layer. Right now I can't have multiple instance of HostableWebCore share the same port and that's heartbreaking.

Finally I wish there was a way to manage the receive loop externally so I have my own listener sitting under this thing pulling messages of of HTTP.SYS, I can just push these requests into the pipeline myself. Decoupling the pipeline from a direct dependency on HTTP.SYS would be a nice thing. I'd like to be able to swap out HTTP.SYS entirely in favor of my own sockets-based receive loop if I wanted to do such a thing. It's true that most scenarios would just use HTTP.SYS, but the ability to have different listeners is a good proof point for the architecture IMO. I also have a couple of crazy ideas floating around in my head that would use this capability, but I'm not quite ready to go public with those yet :)

To finish this off, here's an example of some hosting code that I'd like to be able to write:

public static void Main()
{
    var pipeline = new PipelineHost()
    {
        Port = 80,
        Hostname = "*",
        UrlPrefix = "mysite/myapp",
        
        Modules = 
        {
            new OutputCachingModule(),
            new SessionStateModule()
            {
                Provider = new SqlSessionStateProvider()
                {
                    ConnectionString = "Server=myDb;IntialCatalog=ASPNet;IntegratedSecurity=true"
                }
            }
        }
        
        Routes =
        {
            new Route()
            {
                UriTemplate = "customers/{id}",
                Handler = new CustomerHandler()
            }
        }
    }
    
    pipeline.Start();
    Console.ReadLine();
}

There are obvious issues around separation of concerns here when you define the behavior of the app completely inline like this. However, there are lots of ways to address those; the fact that the app can be be written this way if you want to is another one of those leading indicators that you got the arch right.

What do other folks think?