What Zope can learn from Mozilla
September 17, 2008
Mark Ramm’s keynote at DjangoCon, A TurboGears guy on what Django could learn from Zope, has made the rounds in the Python blogosphere this week. His main point is that other projects will always have more talented people than your project. That’s why it’s always a good idea to be open, share technology and work with others. The real point, however, is that you can learn from each other’s mistakes (and he specifically advises Django to not repeat Zope’s mistakes).
This brings me to an interview with Scott Collins, published by Ars Technica in July 2004 (sic!). When asked about the mistakes Mozilla had made in the past, one of the things he mentions seems awfully familiar:
We made a version of COM, called XPCOM, a fundamental piece of every component of every part of the software. We took COM all the way down to the lowest levels of the system, and I think that XPCOM is a fantastic useful tool. We had great and important places to use it, but we used it too deeply, we allowed it to influence our memory model across the board, and there continue to be costs associated with that which I don’t think we need to be paying. I feel bad that I let it go that deep when I continually fought against it, but I am one of the perpetrators — I wrote some of the machinery that made it easy to use COM, and that allowed people to go deeper and deeper, which we knew was a mistake.
I’ve been saying this for years, and people tend to think that I’m damning COM unconditionally, and I’m not. COM is very important to us, and it’s a foundation of our scriptability layer, and scriptability is fundamental to how our application works. But I don’t think every object should be a COM object. We are finally moving away from using COM for everything, and maybe a synergy with Mono will help us get to the right level of differentiation between objects. This is a deep engineering thing, but I believe that fundamentally that we took the COM metaphor too deep and we paid a price for that: we could have more performance sooner earlier on if we had recognized and stuck to limits in our use of COM.
Most of this statement would hold true for Zope if you replaced “COM” with “Component Architecture”, even the bit about the speed. I’m not saying that the CA is slow, but it’s making us write stuff in complicated ways which seems to end up slowing down everything as a whole. Not to mention developer speed and developer learning speed. We had to build a whole framework on top of Zope just to hide the complexity of the CA for beginners.
Mozilla has learnt its lesson and refactored its code, especially the Gecko rendering engine. I wouldn’t be surprised if the speed and memory improvements in Firefox versions 2 and 3 are in part due to reducing the overuse of XPCOM. If you now think Zope hasn’t learnt its lesson yet, it’s not quite true. The Repoze guys have taken great ideas from Zope and re-implemented them in a much simpler manner that doesn’t need the Component Architecture and works well with others (by [ab]using WSGI) and makes them scale incredibly well. Examples:
- repoze.tm2, a WSGI middleware that allows application-wide transactions (an alternative to having the transaction handling mangled into the object publisher)
- repoze.who, a WSGI middleware for authentication (an alternative to Zope’s
- repoze.urispace, an implementation of W3 URISpace which describe a method to define arbitrary application policy based on URL paths (an alternative to Zope 2’s acquisition and Zope 3’s local components)
- repoze.errorlog, repoze.profile, repoze.debug, etc., which are various WSGI middlewares that take responsibility out of the object publisher
This isn’t to say that the Component Architecture isn’t useful or elegant because it is. But after having spent nearly two years helping create a framework that tries to hide the complexity of CA (over)use, I think it’s time to change gears a bit. The Repoze guys have pioneered it, now it’s time that Zope itself embraced it. If I were to pick, the publisher, its publication machinery and the traversal code would be the first to undergo this treatment, and Martijn seems to have those on his list as well. But Zope is bigger than just the two of us.