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