Forum OpenACS Q&A: Evaluating Web Publishing frameworks
The presentation I am reviewing is:
Ian Kallen, Manager of systems and software at Salon.com presented this, um, presentation about their choice of publishing and workflow framework. If you know about these topics already you can quickly skip through nearly half the slides.
His conclusion is to go with Apache, mod_perl and mason over a fairly large range of open source and commercial options.
I whole heartedly agree with nearly all of his reasoning.
However, I think that he missed a great possibility (especially with regards to workflow) when he disregarded the ArsDigita Community System (now OpenACS) with the following silly (and unprofessional) takedown:
Phil Greenspun has spoke extensively but unconvincingly of the virtues of the AOLServer. We don't agree that Tcl is the world's greatest language and Alex seems nice and everything but a good dog doesn't make a good publishing technology.OpenACS addresses many of his complaints against the other competitors and shares most (not all) of it's flaws with his chosen platform.
mod_perl and mason is a killer combination that I am growing to love, but in situations where OpenACS is an appropriate choice, it can save you 6 months to a year of development time. Seriously.
Here are my notes from reading these slides:
It would have been nice to have a breakdown of the weaknesses of tcl and AOLserver as was done for PHP on the following slide:
tcl+aolserver+openacs doesn't have the PHP weaknesses as far as I understand them. Nor does the openacs api have the weaknesses outlined with java api here:
or the perl api here:
or mod_perl here:
or dbi here:
In fact, "they" seem interested in using PostgreSQL here:
Maybe this criticism of apache+mod_perl has some insight into why tcl+aolserver+openacs was not chosen: not enough of a mature "CPAN"ish tcllib?
These comments about their future plans seem similar to some current openacs functionality (rss?) and the xlm parcer and discussions that are going on here (now) regarding xml, xslt etc:
The reasons for not using ZOPE are interesting.. at least the part about ZOPE re-creating internal sw instead of integrating with other components:
Is this MASON technology similar to the "include" tag functionality in the openacs templating system?
The slide you have linked to talks about Mason's autohandler and dhandler functionality and parallel component trees.
dhandlers are basically equivalent oacs .vuh files
autohandlers are equivalent to our templating tree (master includes child etc.) except the other way around - inheritence is implicit and you need to flag if you want to ignore it for a particular file rather than request it (as oacs does with the <master> tag).
The parallel component trees is quite a nice feature. You can include a component (ie. a small include chunk) with relative or absolute paths as you would expect. But you can configure multiple component roots. One will always bee your www doc root, but you can have other library roots.
So if you do this to include two components:
<& /foo/bar.comp optional arguments... &>
<& /themes/client1.comp optional args... &>
Then these multiple file paths can be searched on your disk in orderl (like how a compiler searches for include files for example).
This means that in the example above, the theme include could be shifted to an nfs volume without having to change any of the rest of the file organisation or site coding.
Other than this multiplpe path searching, it's exactly the same as oacs includes.
So, I wrote that stuff in the summer of 2000 when I was at Salon (I left about 3.5 years ago) but the basic premise that "content that can be materialized as mark up, should be" still stands. To this day, too many sites needless roundtrip to their databases to perform redundant operations to render mark up on the fly. Assemble components as early as possible into the most basic reusable parts, bind late only as much as dynamic presentation requires it.
At the time, rebuilding the infrastructure there with HTML::Mason was the right thing to do (and they're still using the same CMS and basic production server configuration, so I musta done something right). If you're interested, the CMS technology eventually saw another incarnation as Bricolage (see http://www.bricolage.cc/)
Thank's for your comments Ian. In retrospect my message should have been structured more as "how are we going to attack this common perception" rather than "the author missed something".
I have been using HTML::Mason quite intesively at both a major Australian telco and an investment bank.
While language wars can be dumb, tcl (and especially tcl under AOL Server) can be clumsy with namespaces etc. (at least it has name spaces cf. PHP) and has even weaker OO support than Perl (whose OO I quite like).
But in the end the language is only a part of some whole. Perl may not be a better language than Python, but Perl has CPAN. I vastly prefer Perl over tcl, but OpenACS is written in tcl and OpenACS gives you a lot. etc.
Bricolage is very interesting as is Maypole.
As you are obviously involved with Web-based content delivery I would be interested in hearing your current project and views on the state of play in the online world, if you have time.
E.g., "We don't agree that Tcl is the world's greatest language", and all the rest of your statements about ACS quoted above, are simply irrelevent nonsense - straw man arguments that have nothing to do with any of the real issues you were actually discussing, and never did. In fact, you actually said nothing relevent about the ACS whatsoever. Not good.
If the truth is, "Based on my past experience I don't like Tcl, and other than that it uses Tcl I don't really know that much about the ACS or AOLserver, and don't have the time or inclination to investigate it.", then say so. Don't make up BS instead.
Please try to achieve a higher level of honesty and rigor in the future.