That is why i said it seems a little late. I remember stabbing my eyes out when i first got into rails once i tried deploying stuff, back in the fastcgi/lighttpd days.

btw, switchpipe is going to rule the world in a few months, the support for all the other frameworks looks awesome.

To be fair, fastcgi wasn't /too/ bad IF you actually had it running well at least once g and that varied incredibly from machine to machine, alas. It did use a similar underlying mechanism to most of these other alternatives, just in a rather messy way.

I don't think SwitchPipe will rule anything, but perhaps once it's up on Github (instead of SVN) and I release the next version, more baby steps can be made. I'd love to make it even more simple somehow, and perhaps port it to a much faster base (probably Python).

Yeah, I've had good luck with mod_fcgid, actually. I don't have that much traffic, but I like the fact that the software takes care of setting up and tearing down new instances of the application server, rather than having to take a wild guess at how many mongrel instances might be needed per virtual host. This is something that mod_rails also promises to do well.

fair enough :)

What would be the main advantages switchpipe has over the conventional mod_rewrite solution under Apache?

I assume you mean over using mod_rewrite to do proxying direct to backend app servers?

If so: - SwitchPipe controls backend app server processes. If an app isn't being used, it doesn't need to be running. - If an app is under heavy demand, I want more instances (up to a limit) to be launched to deal with it. - SwitchPipe deals with all of the port numbers. No port numbers to deal with as a user.

Just some minor points, but with big usability gains.