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 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.

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'.

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.


Zope3-dev mailing list

Reply via email to