Back in 2002-2004, I was part of the team that redesigned a lot of code for Zope 3. The publisher was one of the first things we redesigned. While I’m sure ZPublisher started out pretty clean when it was first coded, over the years it had grown massive special cases and odd dependencies. For Zope 3, we reduced the publisher to something clean again and provided a way for it to grow as requirements grew.
Unfortunately, it seems the growth strategy did not work. The publisher I see now in Zope 3 is spread out among at least 3 packages (zope.publisher, zope.app.publisher, zope.app.publication) and it’s quite a tangle. Sure there are interfaces, but a lot of code calls undocumented methods. It especially saddens me that the publisher implements its own version of object traversal rather than use zope.traversing.
We can’t let this code languish. Remember what the P in Zope stands for? We have to get this right.
So what went wrong? Perhaps we didn’t provide the right kind of extensibility. We provided a series of documented hooks (the IPublication interface) that applications like Zope could easily override. Wait, did I say “applications like Zope”? Over the past 5 years, most Zope development has focused on building solid libraries with minimal dependencies, rather than building another application like Zope 2. The audience has changed, so the requirements have changed.
I think zope.publisher is a classical framework with all the classical problems of a framework. I suppose we could try to solve the problem with another cleanup. We could mash together zope.publisher, zope.app.publisher, and zope.app.publication in one package, which would untangle a lot, but that package would probably have a lot of unnecessary dependencies. Then we could factor stuff out of that new package to reduce the dependencies. After all that work, though, the publisher would still be a framework. I expect that it would yet again accumulate special cases quickly.
The Repoze team may have provided a different solution to our publisher woes. They have built a system based on WSGI filter pipelines. I’ve looked at Repoze and I’m very intrigued. For example, if you want your application to support Zope-style transactions, all you have to do is include a transaction manager in the pipeline; no extra baggage will come along, now that the transaction package has been split from ZODB. It seems like most functions of the current publisher could be rebuilt on this design. This is a different kind of extensibility that could control cruft accumulation much better.
So, should we replace zope.publisher with Repoze packages? How would others feel about that, particularly the Repoze team? It’s really fortunate that the Repoze packages are BSD licensed rather than GPL, otherwise I would not even consider this.
This is not yet a proposal. This is just a little discussion that happens to span the planet. The next step, if this idea doesn’t get shot down, is to create a more formal proposal. The proposal would specify which Zope release should deprecate the current publisher packages. (3.5? 3.6? I don’t know.)