Forum OpenACS Q&A: Response to nsjava staus

Yeah - the bytecode compilation will be a big issue. This is biggest porting issue I've identified, and probably beyond my TCL-hacking skills. However, I am in touch with David Welton, author of mod_dtcl (which caches bytecode, as does mod_perl.), who offered to help me with this. I may have to forego FastCGI short term and just stick with mod_tcl for now if bytecode-caching stretches my scripter-brain too much (even with David and Michael C's help.) The rest of the issues (nsv's, adp, filters, scheduled procs, connection pooling) aren't too bad or have prior art to pull from that I believe does fall within my abilities.

Listen, you've been hammering away on performance, but I maintain that raw performance is a straw man w.r.t. a portability strategy. It appeals only to (some) coders, not the people you'd want to target with a refined marketing campaign. I studied engineering in school, and can appreciate well-architected software as much as the next guy. But, seriously, how many times has anyone been in a meeting where somebody says, Darnit I'd like to go with that apache|iis|netscape web server, but it just doesn't do enough pages-per-second for my taste. Hands up, how many current OpenACS users actually *need* it's capacity to fill a T-1 on a $1K modern server? I worked at a site last year with 10 million unique visits a month running on Cold Fusion 4 and IIS. Awful, ugly, terrible architecture, but moving to something else so they could have a fractionally smaller web farm was pretty low on their list of priorities. I bet that's true for almost all sites with any sort of legacy dynamic code (it has been in every case I've seen). OpenACS is a great sell if you've got no legacy code/db's to integrate with. Isn't that everyone's experience when they go pitching it to clients? A portability strategy that addresses this would be a big win.

From my blog:

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.