I’ve been working on a new revision of the Zope publishing framework. The goal is to make the publisher comprehensible. Since I helped design the current publisher, I don’t mind saying that the current design really stinks. We made it extensible in a way that breeds ravioli code. I find it difficult to follow the sequence of interactions in the code without concentrating hard and memorizing a lot. That is not acceptable.
Now that I’m working with Zope most of the time, I can try to clean up the mess. I decided to try out a Repoze-like design that builds on a WSGI pipeline. (WSGI did not exist at the time we invented the current zope.publisher.) I’m trying hard to maintain compatibility with the current Zope publisher, so I’m copying from Zope rather than Repoze, but taking ideas from Repoze as much as possible.
I’ve been pretty happy with the new code, but it wasn’t until last night that I felt a click that told me this new design can work well. The key is to use the Zope component architecture to build the pipeline dynamically. In order to cope with all the strange things the publisher has to do, the system varies the pipeline according to the request type. Now any developer should be able to easily plug in pipeline elements with ZCML. People can also build a static pipeline if they want, but I think that would involve a fair amount of work to maintain across software upgrades. I expect the standard dynamically configured pipeline to have 12 stages or more.
The best part is the new design seems to have fewer concepts than the old design. IPublication is gone, along with publication factories; now we just have request factories. Dependencies should be under control as well.
I’ve been checking the sketched code into my sandbox on svn.zope.org. I hope to get the code working soon so I can get feedback on the new design.