Forum OpenACS Q&A: Evaluating Web Publishing frameworks

I just posted this review and link on my developer blog ppl may be interested in.

The presentation I am reviewing is:

http://www.arachna.com/edu/talks/iswp/slides/index.html

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.

Collapse
Posted by Torben Brosten on
For the record, here's the reference to the above quote:

http://www.arachna.com/edu/talks/iswp/slides/non_apache_2_of_2.html

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:

http://www.arachna.com/edu/talks/iswp/slides/php.html

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:

http://www.arachna.com/edu/talks/iswp/slides/servlets.html

or the perl api here:

http://www.arachna.com/edu/talks/iswp/slides/mod_perl_2_of_2.html

or mod_perl here:

http://www.arachna.com/edu/talks/iswp/slides/bob_mod_perl.html

or dbi here:

http://www.arachna.com/edu/talks/iswp/slides/bob_dbi_1_of_2.html

In fact, "they" seem interested in using PostgreSQL here:

http://www.arachna.com/edu/talks/iswp/slides/bob_dbi_2_of_2.html

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?

http://www.arachna.com/edu/talks/iswp/slides/mod_perl_1_of_2.html

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:

http://www.arachna.com/edu/talks/iswp/slides/future.html

The reasons for not using ZOPE are interesting.. at least the part about ZOPE re-creating internal sw instead of integrating with other components:

http://www.arachna.com/edu/talks/iswp/slides/zope.html

My question:

Is this MASON technology similar to the "include" tag functionality in the openacs templating system?

http://www.arachna.com/edu/talks/iswp/slides/bob_mason.html

Collapse
Posted by Mark Aufflick on
Good comments Torben.

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.

Collapse
Posted by Ian Kallen on
OK, so you caught me. I had a blatant bias against tcl (sorry, it still isn't my favorite, but that's the way it goes), all of the tcl code I'd had to work with had always been really messy (about as bad as a lot of the php code I've had to work with).  A few years after that, I worked with some tk/tcl code that didn't suck as much. But hey anyway, language wars are dumb, people have proven time and again that they can write crappy code in any language ("and some of my best friends use OpenACS"). Perl certainly has a reputation of mess-making as well (all of the "free CGI script" sites of the 1990's gave Perl a bad rap, IMO) but I've found that creating well structured and legible code in  a collaborative environment is something I can easily support and lead on.

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/)
-Ian

Collapse
Posted by Mark Aufflick on
Wow - talk about the horses mouth!

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.

Collapse
Posted by Mark Aufflick on
Of course I could always just read your weblog myself ;)
Collapse
Posted by Jade Rubick on
The language doesn't matter all that much -- the API does.
Collapse
Posted by Andrew Piskorski on
Ian, having personal biases or opinions for/against particular programming languages is ok, and making recommendations based on those opinions is also ok. But making up nonsense in order to obscure the fact that your recommendations are, in fact, based solely on a few such personal opinions is not ok.

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.