[Zope-dev] Re: Exposing the simple publisher (Re: Re: Reducing dependencies of zope.publisher)

[Jim Fulton]

On Mar 25, 2008, at 4:41 PM, Chris McDonough wrote:
...
> Two nits:
>
> - I don't like the fact that zope.publisher.publish uses the  
> "setResult" API of the request to handle the result returned by the  
> published object..

You mean the response....

> why wouldn't it just return the result?

Because the response object is likely to do additional processing.  It  
is likely to set response headers at a minimum, but it may do much more.

> Maybe this dance was cargo-culted over from Zope2.

I don't think so.

> - I don't like that the request handles traversal.

It doesn't do much more than break the path into segments.  All of the  
actual traversal is performed by the publication. The publication  
doesn't have to consume one segment at a time.  It can consume the  
entire path on the first traversal if it wants to.  It can also do  
traversal during initial object computation.

>  This also smells like it was cargo-culted from Z2.

I don't care for this characterization.  When we did the Zope 3  
publisher, we borrowed heavily from the Zope 2 one.  The Zope 2  
publisher is pretty heavily battle tested.  I like the fact that  
traversal is done a step at a time. It allows me to distribute the  
traversal logic.  If an application wants to traverse on the URL as a  
whole, they can do that in the initial object selection.

>  Why shouldn't the publication itself do traversal?

It does,

>  Traversal is extremely policy-laden, why break the code that  
> implements that policy up so that you need "matching" request and  
> publication objects?

You don't. The request part of traversal is very general and only  
protocol specific. To my knowledge, no one has ever written a custom  
request to implement custom application policy. AFAIK, the publication  
API is sufficient.

BTW, I don't claim that zope.publisher is flawless.  I'd be happy to  
see some discussion of it's strengths and weaknesses for the purpose  
of making it better.   I think my biggest regret is changing the  
request and response APIs as much from those in Zope 2 as we did.  I  
think it would be interesting to look at how difficult it would be to  
reunify the Zope 2 and Zope 3 request and response APIs.  It might  
also be interesting to look at a broader unification as Ian Bicking  
has made some movement toward.

Jim

--
Jim Fulton
Zope Corporation