I think it sounds pretty interesting.
I've long wanted the time to write a version of nsunix for Apache and Squid, and I've also considered a kernel module version of nsvhr, so that sockets could be read, fiddled with and passed around and then have any user program just think they are getting a regular socket without needing any unix domain socket passing. Not because anyone needs it, but because it would seem to be pretty cool.
If you're looking for URL tree code, there is of course, URL tree code to be harvested within AOLserver, assuming the licenses are compatible.
From my nsvhr/nsunix experience, I think it's a good idea to make your application logic independent of the the vhost/cache technology. If I understand what everyone has said, then I would like to see (and maybe help out on), a application transparent tux cache. As other's mention that would probably involve having tux feed everything initially to AOLserver, and having AOLserver fill the cache via your tux syscall. I would imagine that the soon enough, tux would be serving the static pages out of its cache.
I haven't examined your code, but the other suggestion I have is hacking it in the best way you can to nssock directly. AOL seems averse to supporting much beyond nssock, and nssock has certainly been well tested -- I can't say the same about the drv.c driver approaches.
