Straw Men & FastCGI
So DonB and I have been going back and forth on the merits of FastCGI
support as a way of achieving broader platform support for OpenACS.
I'm guilty of being sucked into the straw-man of performance that he's
brought up. I think it's a non-issue, and probably shouldn't have
attempted to prove that FastCGI can be comparable. Putting down one
technology to promote another is not necessary. Portability has costs,
yes. Performance is a negligible one.
Also, the longer-term back-of-my-head plan which I'm guilty of not voicing
more clearly is that I *want* a simple, unified, high-performance AOLServer
stack to remain the preferred platform. I want to be able to deliver to
clients a solution that runs on their preferred infrastructure, but has
compelling benefits when run on it's native reference platform. That's
exactly the kind of platform advocacy Microsoft is pursuing by pushing
Rotor, and not-yet-suing Mono. They know both are going to suck, where
suck means lags the Windows version by a good two years. But they can point
to it, and it will allow them to attract a few fence-sitting *nix types to
their camp. And maybe convince a few universities that they can write
courses about their stack without making MS endow too many chairs.
People will build on Mono. Their code will work. And the clients who use
that software will become potential customers of Microsoft's .NET Server
stack (where the real money is).
I view the OpenACS/FastCGI project the same way. The customers that adopt
it, who aren't ready to rip-and-replace their current infrastructure, will
have one more excellent reason to consider doing so in the future.
In closing, there are 100,000 apache servers deployed with mod_fastcgi
compiled in, according to this survey. Not too shabby.
9:03:25 PM
|