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 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list