Forum OpenACS Q&A: Response to Article on ACS x Zope
Now I'm entertained! We need at least one good flame war on these forums, and now we have it.
"""
He started it. 😊
"""
What bothers me is that no real arguments have been presented here to make a point about Zope. If you're posting on the OpenACS web site (which you're more than welcome to do!), it behooves you to make a solid point about why you think Zope is good before we go out and take you seriously.
"""
Actually, my original post was in response to Titus' "Why Zope Is Evil" article referenced in the discussion... I am interested in ACS, it's reputed to be very good, and I had hoped to get an answer to a specific question that I asked about ACS' accesibility to new users which was answered (very well) by Robert Mello. I have no genuine desire for you to take me seriously beyond that, though I've been having quite a good time bickering with Don since then.
"""
In particular, the idea that OpenACS / ACS is not as good as Zope because it includes "too many" differently named elements (Tcl, SQL, ADP) is laughable. So if we called it Qtcl, QDB, Qweb, would it be less confusing?
"""
If someone said this, it wasn't me. Believe me, we've got our own acronym problems. 😊
"""
Look, I'm perfectly open to the idea that we can learn something from Zope. But let's see some *real* arguments here, objective advantages, not warm-and-fuzzy arguments about what "feels more consistent" or how smart Zope developers are.
"""
OK. I like the fact you've brought up specific points that I can actually address instead of insulting my mom or something. 😊
"""
Note that OpenACS is *not* willing to compromise on certain things: ACID compliance of the data store.
"""
Nor is Zope. See http://www.zope.org/Members/jim/ZODB/TransactionsAreImportant. It's actually just Jim referencing your website (wait, your article personally!). We know transactions are important. Every request to a Zope method is conducted within transaction boundaries. The ZODB does ACID, and SQL transactions are by default encapsulated within requests to the ZODB. This means that you can modify objects via the same method call within the ZODB and within a transaction SQL datastore (Oracle, Postgres, Sybase, and Solid currently, IIRC) in the same transaction and retain the ACID behavior of both. Both datastores will be rolled back in step with each other if the containing transaction fails. Writes to the default storage implementation (FileStorage) are all appends to a single file, and we're very careful about the bits. I am currently developing a Zope storage that uses Interbase instead of the filesystem (see http://www.zope.org/Members/jim/ZODB/RelationalStorage). You can see more at the ZODB UML model or you can read the article linked at starship.python.net that I gave earlier. You can also read Jim Fulton's ZODB3 presentation for the yearly Python conference at
http://www.python.org/workshops/2000-01/proceedings/papers/fulton/zodb3.html
"Efficient calculation of aggregate information"
We interface to SQL if that's your bag, and we have additional cataloging machinery for stuff stored the ZODB that's somewhat more flexible than many SQL engines for full-text searching (I have a rough time with LIKE, I'm no RDB person myself, how does one efficiently full-text search an Oracle or Postgres DB?). It stores references (path locations) to objects as well as metadata (cached attribute values and method return values of arbitrary objects), and provides more traditional indexing capabilities. We also have the concept of "pluggable brains" which allows us to wrap return values of SQL data into a class instance to give it additional functionality. We are hoping to extend the cataloging machinery of the ZODB to handle SQL datastores RSN.
"""
Scalability to millions of hits per day in practice, not just in theory.
"""
I concede this point. The biggest Zope website I know the actual stats on (Zope.org) gets about a hundred thousand hits a day on a single server. It's not taxed, but I have no available empirical evidence to present to show that it would go any higher. We've addressed this considerably with ZEO (Zope Enterprise Option), which used to be a commercially available product packaged along with service but has been open-sourced and is being packaged for general consumption and will be released hopefully within the next few weeks. It allows you to use mutliple Zope clients (no theoretical maximum limit) on arbitrary machines against a single 'storage server'. Each client keeps an object cache, so reads are relatively cheap. Writes are more expensive. It's well suited to web applications in which most hits are reads. The storage server invalidates objects in each distributed client's cache when it notices an object has changed in storage. Invalidating client caches is what makes writes expensive. More info on ZEO is available on the zope.org website.
"""Quick learning curve"""
I definitely concede this one. We really fall down here. We *really* fall down here.
"""and rapid development. """
Once you get past the learning curve, I think we've got a good rapid development story (if that's not an oxymoron 😊. We obviously use Python, which is a great interpreted scripting language, that makes things a little easier than having a compiled language like Java (I'm sure the same is true of TCL). We've got ZClasses which are classes that you can create through the web, whose methods can be traditional Python code, DTML methods (a templating and presentation language), SQL methods (methods that return values from SQL datastores), and various other things. I'm working on a project right now with the development team of a customer using Java to write a web client app, and we're constantly ahead of them, even though IMHO they are very smart, it's just faster to implement in our environment. I'm sure Don will jump in here and claim that this is not meaningful because I haven't presented their resumes to him nor mine. Nyaaah.
"""
I'm sure Zope has a few things to teach us. I invite you to take into account these important restrictions and submit a real proposal for how we can benefit from Zope's approach.
"""
This is sort of a heavy task. It would help if you read some of the articles and documents I've linked, after which I'd be happy to answer any questions you have. I'm not here to convert anybody. I've heard very good things about ACS and I hope to find the time to install it and maybe steal a couple ideas from you guys (I think actually I'm going to try to steal this bboard idea from you, it's really very well done, except I'm going to try to make email work both in and out, have you thought about trying that?). I think that against my better judgment I just let myself be trolled, this explains my extended stay. 😉
An aside: have you noticed that the email URL generated by bboard doesn't actually point to the discussion forum that the email references, but that it points to the container for the discussions?
