[Zope3-dev] PEP 333 and Zope

[Eckart Hertzler]

On Tuesday 09 November 2004 17:04, you wrote:
> At 03:13 PM 11/9/04 +0100, Eckart Hertzler wrote:
> >I am a contributor.
> >So I could check it in.
> >
> >However, since it uses philips refernence implementation it has a 
> >dependency to
> >this (external) module which is in the PEAK repository.
> 
> You could just check in the application part, for starters.  There are 
> plenty of WSGI server implementations available, including the one from 
> 'wsgiref', and they're more important than whether a SimpleHTTPServer runs it.
> 
> However, looking at the code, I see a few issues.  
I would have been utterly surprised if there had not been some issues. ;-)

> Rather than having the  
> server set PublisherApp.request_factory, this should be just done with a 
> subclass, so that a given subclass of PublisherApp is a valid WSGI 
> application unto itself.  This is needed for servers that expect to simply 
> import an application object from somewhere, and it's also just a bad idea 
> to change the class variable like that, because it means you can't have two 
> different ZPublisher-based apps running in the same server, if they have 
> different request factories.
> 
Yes, I knew it was dirty. It was a pre proof of concept like I said.

I will try to improve this based on your suggestions.



> The second issue is that your implementation won't work properly for 
> streaming output or large files, because you're buffering all the data in 
> memory, duplicating the buffering that already exists in a publisher 
> response.  Instead of a StringIO, you need to create a simple file-like 
> object that wraps the WSGI 'write()' functionality.  The only case in which 
> PublisherApp.__iter__ should yield a value is if the response wasn't 
> actually sent to the output stream.
> 
> 
This was due to my limited understanding of the publisher internals.
It seemed to me, that the publisher produced the body in one block, so
I did not see how streaming might happen...