Forum OpenACS Q&A: Response to Article on ACS x Zope

Posted by Chris McDonough on
> Why? Lots of people have experience with OO.

This is true.  I've also seen that there are a lot of programmers out there who don't, especially in the field of web development.  I had many responses to that article from people who know Perl, VBScript, and PHP, and never use to a great degree the OO constructs of any of these languages.  Zope makes really heavy (some might say absurd) use of inheritance; not to mention our homebrewed 'acquisition', which is something like inheritance but is containment-based.  This stuff is pretty central to Zope, which takes a little getting used to for non-OO types, and even sometimes for OO types.  The use of these features combined with our hideous documentation is why Zope is hard for people to get cranking on quickly.

In our defense, bringing an end-to-end object model to the web is something of a new and foreign thing, and AFAICT, Zope and Apple's WebObjects are the only two products that honestly try to do so.  I know most of people just want to get something done and not have to worry about what is going on inside.  But I do think that building web apps in terms of objects is a good thing, if only because it frees you from needing to think about webdev stuff in terms of 'pages', and instead lets you think about your site in terms of how pieces of code can interact with each other, how you can build interfaces to applications that let folks use them not from just within the application UI, but via XML-RPC/SOAP/CORBA/RSS, etc without needing to strain yourself by building all the machinery to talk to these things from scratch.

This is something of a religious point.  I certainly do not mean to say that large-scale applications can't be written in terms of dynamic pages or in terms of writing procedural code that goes and grabs stuff out of SQL and displays it to the user.  They are two very different approaches that share parts of the same goal.

>      I just keep getting this feeling that you folks are making a

> mountain out of a molehill. ACS-backed websites are by no means

>      "simple websites",

I didn't claim they were, on the contrary!  My apologies if you thought so, please read the sentence again.

> the toolkit's relatively simple because the problem of creating

> complex websites is relatively simple. It's the

> pieces you glue together that are complex. The datamodel's the most

> complex piece of the ACS itself. That's the way it should

> be.

This seems to be the major point of divide between ACS and Zope... we don't have a datamodel.  Instead we have objects that have interfaces.  You have data that sits in an RDB, then you have code that operates on it.  We have objects that contain both code and data, by way of the ZODB.  Even stuff that's in an RDB external to Zope can be represented by Zope in terms of instances of a class ("pluggable brains").

A little dig, here, my pre-proposed apologies.  I hope I don't get flamed too hard.  You guys have been working like mad to port ACS over to Postgres.  This is a lot of work.  It's a lot of work because there seems to be only a thin layer of abstraction between the code that makes up ACS and the database table structures.  There's a lot of dependencies there, I presume, which is what makes it hard.

OTOH, Zope has a Storage interface that you can back up with whatever serves your purpose.  The "default" storage is a FileStorage, that is one big honking file on the Zope server's HDD.  But one of the other uses of the Storage interface is our failover stuff, ZEO.  It lets us frontend a single "storage server" with multiple Zope clients which serve as webservers.  Despite the complexity of the task, the code that lets us do such a thing is less than 100k (total, with docs).  This is pretty amazing to me.  Solutions like, for instance, Allaire Spectra, have megabytes of code to go do this, and then you need to go make sure your RMBMS is partitioned and synced properly across a number of machines besides.  I'm somewhat attracted to the elegance of the Zope model when it comes to stuff like this.  It just feels right, whereas other solutions feel.. well.. clunky.  This isn't to say they don't work, I'm sure they work fine.  But I like the fact that the haystack is potentially partitioned into 100k, when the needle can be a single byte.

Another point:  Jimmie Houchin referred to a RelationalStorage in the works for Zope.  I am one of the folks writing this beast.  This code will let us store all the ZODB information inside a relational database.  It doesn't much matter which kind, because the whole implementation is less than 8k, and I can rewrite it in about 12 hours.

These sorts of flexibilies are possible because we're using an object model inside Zope and because we're trying desperately (and sometimes succeeding) to write cohesive interfaces to those objects.  The next step is to make more apparent that power to end users of the product by writing applications against Zope and documentation for Zope that exposes it.

We know have a *long* way to go, and it's clear that we can take some pages out of the ACS book when it comes to packaging something that makes people productive quickly.  Parts of Zope are still somewhat of a framework that DC uses for consulting engagements, though most of it has quickly grown into an application server or content management system in its own right.  We need now to concentrate on hardening the interfaces to the less clear parts of the framework and documenting them.  Hopefully, at that time, the time we put into the architecture will pay off.  Maybe not, in that case I'll be out of a job.  :-)

>      Why invent persistent store (ZODB) when there are proven

> database engines - object-oriented as well as relational -

> available? It's this "we need to build it all" mentality that I

> think leads to a lot of the complexity.

DC was (and is) a Python company at heart.  AFAIK, at the time it was determined that there needed to be a persistent object database to front end Bobo (that was Zope's name at the time), there were no affortable OODB alternatives that had Python interfaces.  Jim Fulton is something of an OO "zealot", so using an RDBMS to store object data was not an option in his mind.  So... he made his own OODB  :-)  Mine is not to question why.  He did it, it's solid, and it's pretty damn useful.

In more general terms than the ZODB, I think you're right, however.  Zope needs to cater more to people's existing skillsets.  This is where we think that applications like the Portal Toolkit, further community contribution, and better documentation will help.