Redesign of zope.publisher

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.

5 thoughts on “Redesign of zope.publisher”

  1. I think these are very good ideas — especially making requests and responses inert. I do not quite understand them at the moment, but from looking at Grok’s skin and layer support, I think that inertizing the request object in particular is really needed if Zope is going to become at all comprehensible to normal web developer terminology.

    But at the same time, I’m not an expert who can really comment on your specifics. I’ll post a link to this to the Grok mailing list and see if I can get Martijn to respond to you.

  2. It sounds good from the perspective of someone fairly uninformed about the specifics. If you can let me know about specifics things people can do to help, I’ll look into helping.

    Concerning Brandon’s comments about skinning; I think we should continue with approach to provide an additional skin layer to the request. Of course this affects traversal, but the request *will* affect traversal anyway. The point is that the request shouldn’t have code that is involved in traversal.

    I’ll also comment that Zope’s request object is factored out into all sorts of base classes to a rather great extent. I can see how some of the base classes might be useful now to support a test request, but what other purpose do they really have? We should consider whether we cannot flatten this hierarchy significantly. What I’d like to explore as well is a way to start using the webob request and response objects, as they’re a nice WSGI-based library that just cares about web framework request and response behavior. Perhaps we can at least start using them underneath and let Zope’s request and response object adapt them for backwards compatibility’s sake?

  3. Hey, Shane, it’s great to know that you’re interested in contributing to the Zope core again. I am quite distant from Zope nowadays. But from a distance, your post made me wonder: is that what Chris McDonough and others are doing in Repoze?

  4. Repoze is doing bits of what we need (which is why Shane mentions we should use Repoze packages wherever we can). Shane’s project is to overhaul the existing Zope framework publisher though. repoze.bfg has gone another way and has instead created a much simpler publisher that isn’t trying to be compatible to Zope’s in any way, as repoze.bfg is a new web framework based on zope concepts and smaller bits of the Zope framework than the Zope 3 app server or Grok do. If we want the Zope framework to evolve we’ll have to do things like what Shane’s doing.

    see also various comments on Shane’s previous blog entry on this: http://shane.willowrise.com/archives/repozublisher/

  5. Pingback: Links for February 10th |

Comments are closed.