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

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.



Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to