[Zope-dev] Re: z3 server+publication refactor for z2

Philipp von Weitershausen philipp at weitershausen.de
Thu Apr 13 09:39:06 EDT 2006


Sidnei da Silva wrote:
> On Thu, Apr 13, 2006 at 11:46:20AM +0200, Florent Guillaume wrote:
> | Hi,
> | 
> | Sidnei has been working on the Zope 2 publication-refactor branch  
> | where he's allowed the use of the Zope 3 Twisted-based server, and of  
> | a Zope 3 based publication process.
> | 
> | I'd like to see this merge branched in Zope 2 trunk because I'd like  
> | Zope 2.10 to be Twisted-based. What's missing from the branch  
> | preventing this? What problems have been encountered?
> 
> Well, the biggest is making an adapter for the Zope 3 request so that
> it implements the same interface as the Zope 2 request. Other than
> that, it was pretty much working.

We might not need a special request type. We could try to continue to
use ZPublisher's request implementation, at least for now.

In WSGI, the "application" gets the env and streams. In Zope 3, this is
the  WSGIPublisherApplication (see zope.app.wsgi). It is responsible for
creating the request, but it chooses to delegate to an HTTP request
factory.  This factory decides, based on certian rules, whether we're
dealing with a plain HTTP/WebDAV request or XML-RPC or browser etc. In
Zope 2, this factory (or the WSGIPublisherApplciation itself) could
simply create a ZPublisher request object. After creating the request,
the WSGIPublisherApplication would turn the request over to
ZPublisher.Publish.publish and sends it on its normal path.

This is the "small" solution in which we provide a WSGI-capable frontend
to the ZPublisher. The "big" solution would be to replace ZPublisher
with zope.publisher and a custom Zope2-oriented publication +
appropriate traversers. In this case I wouldn't advise for adapting the
Zope 3 request to a Zope 2 request. I would rather introduce a new
request type, IZope2Request, based on zope.publisher's IBrowserRequest,
that provides all the additional Zope 2 API.

I think the "big" solution would take a considerable effort. It's less
than three weeks before feature freeze. That is very little time even
for the "small" solution.

> Oh, and now I recall, we don't have 'streaming', 'chunked',

We have something along those lines. Jim can say more.

> and 'gzipping' yet, though the latter two would be easily implemented as
> wsgi middleware (could even use the implementation from
> django/turbogears).

Yeah. Good idea. Perhaps we can see if we can create a common wsgzip
package or something that is open to all WSGI-capable Python frameworks.

Philipp


More information about the Zope-Dev mailing list