Here are my current thoughts on what we should do with zope.publisher.
- Most packages that depend on zope.publisher only use its interfaces and two base classes (BrowserView and BrowserPage). Those packages don’t care about anything else that zope.publisher offers. Therefore, to reduce dependency burdens and to make the zope.publisher package easier to explain, I think zope.publisher should be reduced to providing only interfaces and those two base classes.
- The IPublication interface and all its implementations should die, to be replaced with a WSGI pipeline. This should make the publication process dramatically easier to understand and customize.
- Request and response objects should just hold information; they should have no interesting behavior such as traverse().
- We should create and use two new keys in the WSGI environment, “zope.request” and “zope.response”. These will implement at least IRequest and IResponse, respectively. (“transaction” and “zope.interaction” are also possibilities.)
- The WSGI-compatible pipeline should be capable of doing everything zope.app.publication currently does. We should use Repoze packages in that pipeline where possible.
- Most of the code in zope.app.publisher should be moved to a better-named package like zope.fileresource or something. IMHO, the name “zope.app.publisher” conveys an understanding that does not match the contents of the package at all.
- I think all of zope.app.publication and zope.app.http should be moved out of zope.app and into WSGI pipeline elements. (This is less clear to me than the rest of the plan.)
How would others feel about that plan? It’s a lot of changes, but it could be done in phases, and it seems like a big improvement. I probably need to elaborate more. It’s still crystalizing in my head.