On Mon, 2004-09-20 at 10:07, Donovan Preston wrote:
On Sep 20, 2004, at 12:40 AM, Glyph Lefkowitz wrote:
Let's try to figure out which web server we are supporting and then actually support it, rather than having 9 different half-assed, half-supported implementations floating around.
Well, certainly nobody who wrote the original twisted.web code is supporting it, but that doesn't mean it's unusable. On the contrary, it's very usable, and there are probably lots and lots of applications which depend on all sorts of subtle and broken semantics it uses (people being far more interested in developing web related things than finger related things).
The twisted 1.3 release will available for download for the forseeable future, for those who need it. I don't believe we should release stuff with subtle, broken semantics in twisted 2.0 - the release number implies that we are changing a few things, so this would be a good opportunity to abandon support for the old code.
I don't see any sane way to perform a complete rewrite with better semantics while still living in the old twisted.web namespace, especially given the miniscule amount of time most of the major developers of this project have to put against it. Developing backwards compatibility with the old APIs would be a death march, would never quite work anyway, and wouldn't really benefit anyone in particular.
If there is to be no backwards compatibility, why bother with the separate namespace? Do we want to do this with other modules in the future, e.g. twisted.spread2? Our last discussion of this was inconclusive because I don't think we foresaw the web rewrite being so radically different. I guess we have to drag that dead horse out here to beat it one more time ;).
Even if the namespace changes, there should only be one of these in svn at a time. If further development on twisted web 1 is going to continue it should be in a maintenance branch, and then we need to discuss how we're going to manage maintenance releases.
We already figured out which web server we ("we" being those developers who actually care about the web) are going to be supporting. twisted.web2. web should have a deprecation warning in __init__ for a release, and then should be terminated with extreme prejudice.
I would terminate before providing a deprecation warning. If you want to provide a backwards-compatibility release for using web1 with the new reactor core, that's fine, but I don't see any reason to include web1 with the new download.
As far as the nevow dependency, [...] you're not going to get much out of the box.
It really sounds like nevow and web2 ought to be merged. Traffic on the twisted-web list suggests that anyone who is using one is using the other, at least in some capacity. The marketing aspect of this certainly requires some discussion, but it seems that one's utility is greatly reduced without the other, and the dependency is circular. For specialized cases, such as using nevow for CGI scripts, there is no problem with having the other code around as long as it can avoid being imported.