-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bernd Dorn wrote:

On 13.04.2006, at 11:55, Andreas Jung wrote:

...

--On 13. April 2006 11:46:20 +0200 Florent Guillaume <fg@nuxeo.com> 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?

The question is: how complete and stable is this stuff? Does it replace the current implementation or is it an optional feature as in Zope 3.2?

twisted is the standard server in zope 3.2 - zserver is optional

That is really an accident: it is still in "experimental" status, and is known to have a *big* performance loss compared to ZServer. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPnC6+gerLs4ltQ4RAscoAJ9XikAbVs8VnG607zEgN2gLrBXXowCgye40 4XOHEXBeGlTGvFicMxRXXpE= =rPsA -----END PGP SIGNATURE-----

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

Andreas Jung wrote:

<philipp@weitershausen.de> wrote:

...

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.

Big or small? Would this be an optional and configurable feature or replacement of the current infrastructure?

I think it'd be technically possible to have both solutions coexist. After all, that's what we're doing in Zope 3. zope.app.twisted and zope.app.server can coexist easily, I don't see why it shouldn't be possible in Zope 2. Philipp Btw, if new packages need to be created (I don't think Five is the right place for all of this), I would very much like to recommend putting them under Zope2, essentially making the Zope2 package the equivalent of zope.app for the Zope 2 world.

--On 13. April 2006 15:58:44 +0200 Philipp von Weitershausen <philipp@weitershausen.de> wrote:

...

...

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.

Big or small? Would this be an optional and configurable feature or replacement of the current infrastructure?

I think it'd be technically possible to have both solutions coexist. After all, that's what we're doing in Zope 3. zope.app.twisted and zope.app.server can coexist easily, I don't see why it shouldn't be possible in Zope 2.

They must coexist in any case. We can not get rid or replace a major component - neither without breaking compatibility nor without deprecation. -aj -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting