Forum OpenACS Q&A: Response to ACS vs Zope?

Collapse
14: Response to ACS vs Zope? (response to 1)
Posted by Janne Blomqvist on

ACS and Zope come from two very different schools of thought. ACS is more of an evolution of the "page-centric" philosophy most web applications are built on, i.e. most of the stuff done with php, mod_perl etc. AOLserver, php, mod_perl and others all essentially all provide the same essential things, i.e. an in-process script interpreter and db connection pooling. What really makes ACS stand out from these is the sheer number of features it has, and it's all integrated. Certainly you can find some webmail package, some other bulletin board package and a news package in say php which may have some advantages over the corresponding module in ACS. Integrate them with each other? Get prepared for a _veery_ long hacking session.

Zope, on the other hand, is rather different. I have the impression zope really started as an experiment on how to publish objects on the web. What zope essentially is then, is a container for a special kind of objects (I'm not that familiar with Zope, but I think this is the famous ZClass class..). When you request an URL zope checks security etc. and then calls the publish (or whatever it's called) method on the object identified by the URL.

As for Zope Products, they are similar in concept to ACS modules. But as ACS already contains all the modules, it's not really fair to say that there are lots of add-on modules on the Zope site -> Zope must be better. When you do a clean install of Zope you get only the container itself and the security framework.

Last summer I made an intranet site for a medium sized company (about 200 persons) and some web based reporting applications for a couple of db-based applications they had. I had enough independency to be able to choose how I implemented stuff myself, so I evaluated a few of the things available. After some quick looks at php, perl and enhydra (a java app server) I looked a little more closely at ACS and Zope. I ended up with OpenACS primarily because the intranet module had pretty much what I wanted, and I think the RDBMS api of AOLserver/ACS is much better than that of Zope. Granted, Zope has some rather cool features, but I got quite annoyed at the web interface and having to use the integrated object database (yes you can export most of it with ftp/webdav but it's somewhat kludgy, imho, and I like to bang around with emacs, grep and other "classic" unix tools).

This winter I got involved in a startup, and I was tasked with choosing the technology platform. After a rather lot of reading, evaluating and discussing with the other people at the company, I chose Java. Before you dismiss me as another guy-in-a-suit-who-reads-those-really-stupid-magazines let me point out the reasons.

-Everybody at the company knows Java. Recruiting also seems good 
because most universities teach Java at least in their introductory 
courses. 
-Broad industry support. For web applications, Java and MS ASP (and 
soon .NET) are the two technologies most unlikely to go away in the 
near future.
-Name recognition. If we tell out customer we use Java, the guy in 
the suit might get that warm fuzzy feeling. If we tell him we use 
AOLserver + ACS, he's not going to know what it is.
-Lots of documentation
-Lots of infrastructure. Look at all the stuff included in a J2EE 
app server. While most of it may be overkill for many web 
applications, it's reassuring to know that the stuff is there if you 
need it.
-At the time, the future of ACS looked uncertain with Phil evidently 
leaving Ars Digita. Also the fact that Ars Digita were (and still 
are) on the way to convert to Java boosted the feeling that Java 
would be the right choice (and I still feel I made the right choice, 
btw).
-While developing plain servlets or JSP:s is slow compared to 
php/perl/tcl things like JSP taglibs coupled with the "Model 2" 
architecture (see for example the Jakarta Struts project / 
alternatively a plethora of alternatives to JSP exist) provide speed 
of development, and a clean separation of presentation and logic 
(important if we bring in html people who don't know sh*t about 
programming).