On Feb 24, 2009, at 12:59 PM, Shane Hathaway wrote:

> Jim Fulton wrote:
>> I disagree strongly with many of the assertions made in these   
>> articles. (I can't judge the pipeline proposal, since it is only   
>> fleshed out in code.)  While I do think zope.publisher has some   
>> problems, they aren't the same problems that shane sees.
> What are the problems with zope.publisher as you see it?

- It has too many dependencies.  Obviously.

- It has too much in it.  This contributes to the large number of  

- I think the attempt to support multiple protocols through different  
request types has turned out to be a mistake.  I think it was a  
reasonable approach to try, but I don't think it turned out well, in  
part because it seems too heavy.   Last year, I implemented some Ajax  
support framework without anything like the complexity that's in the  
xml-rpc support. I did end up defining a new request marker type to  
facilitate component lookup, but I was able to do this in a very light- 
weight way.

- It's not well enough documented.  While I think there's merit in  
doing some things at the WSGI level, I remain pretty happy with the  
publication interface for separatating generic publisher functions  
from application policies.  I which the use of this API was better  
communicated and understood.

A less major complaint is some baggage from the past. There are a  
number of request features that I never use and tend to forget about.  
The biggest of these is the special form data unmarshalling and url  
manipulation support. (I was amused to read in your introduction to  
your pipeline proposal that people wanted to know the answer to the  
question: "When does Zope respect the :method form variable?". :)


Jim Fulton
Zope Corporation

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to