[Zope3-dev] Twisted Publisher and Zope 2

[Jim Fulton]

Martijn Faassen wrote:
> Chris Withers wrote:
> 
>> Stephan Richter wrote:
>>
>>> I wonder whether a similar approach as the one taken for the Twisted 
>>> server migration is possible. There, if you have an instance running 
>>> on ZServer an upgrade will not cause the switch to Twisted, since 
>>> your startup script still refers to the old server code. You 
>>> explicitely have to change your startup script to start using Twisted.
>>
>>
>>
>> I think this is the way to go and a zope.conf option would be an ideal 
>> way of making the choice...
> 

I'm not sure whether we're talking about the server or the publisher,

> I think it's rather too big a shift. I think that 'the old startup 
> script still referring to the old server code' is definitely one that 
> isn't appropriate for Zope 2; either the new server code is backwards 
> compatible and almost everything will run perfectly, or the new code is 
> not very backwards compatible and most Zope apps will break.

If you are talking about the server, as opposed to the publisher,
I don't see a problem with supporting both the old and new server.
Note that the new server is twisted and is largely outside our control.
There's no reason to expect twisted to be backward compatible with
ZServer.  Also, with WSGI, we can use any WSGI server technology, including
mod_python.  Eventually, we'll phase out ZServer, making it a separate
download.

OTOH, the publisher itself needs to be backward compatible.

> In the former case, hard to reach, I think we just want to upgrade 
> everybody. In the latter case, possibly more likely, a zope.conf option 
> is the least we can do. I'd be more in favor of a granular approach, 
> where I can tell the system 'for this piece of content, use the Zope 2 
> behavior, for that, the Zope 3 behavior'.

Hm, maybe you are talking about the publisher. :)

In which case, I expect this all to be controlled via adapters, so
what you suggest should be possible.  In any case, existing Zope 2
code should function as it does now without change.

> But I think we'll have to see which approach is best when there's actual 
> experimental code; I guess only then we'll be able to judge how much of 
> Zope 2 we can safely replace.

Yup.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org