Before locateChild is made "the way", it has a problem that there is no way to terminate the recursion without consuming all elements of the path. This means it is impossible to write CGI scripts that make use of PATH_INFO. I have a patch on the nevow tracker related to this issue: http://www.divmod.org/users/roundup.twistd/nevow/issue44 afaik, it hasn't yet been adressed, but I've not been following development since I submitted it. My apologies if I'm lagging in information.
there I haven't really thought about, I'm really not as concerned with backwards compatibility as others are, but if it's the consensus of the people working on the split that backwards compatibility is in issue it'll be maintained. Atleast for a few versions
The way I see it is the backporting is part of the stabilizing the current Nevow API.
3) I don't know when all this will be happening, I'm working on backports as we speak but nothing has been done to formalize the effort, no repositories set up no web pages, etc ...
I'm not even sure how I came to be the guy-who-is-doing-this I'm not a twisted developer, I'm not a Nevow developer, I'm just a very frustrated programmer who tried to generate discussion, and somehow started actually working on it.
On Tue, 2004-04-20 at 11:12, Christopher Armstrong wrote:
Alex Levy wrote:
I'm going to back up Richard and Ed, because I feel like people might be inclined to just pass their emails by. This is very important.
Here we have two users who are expressing serious reservations about using Twisted or Nevow because they don't have any details on how we plan to split twisted.web. I can understand their concern: nobody likes being in the dark.
One point I'd like to make is that Nevow has, since its inception, been pretty API-unstable. *twisted.web* has been stable for a while, and there's no reason not to use it. Nevow is obviously still something you need to watch closely if you want to use.
I promise there will be backwards compatibility for twisted.web. I'll explain more below...
1) What will happen to twisted.web? It's a complex module, and doing reverse-imports (the way LowDown is doing with twisted.news) might get pretty rocky. Do we have any guarantees that, for the foreseeable future, the existing twisted.web will not change, and people can continue to develop applications using twisted.web?
'from twisted import web' *will remain backwards compatible*. I'll personally see to that. :-)
2) When everything's finished, how drastically different will the APIs be? Are we talking about a simple "move code over, clean up a few loose ends," or is this going to be a massive reorganization and refactoring of everything web-related?
That's a question that foom and nevow-twisted.web-forkers can answer. nevow changed a bunch of core twisted.web stuff, and foom is rewriting the HTTP support.
And, most importantly...
3) What sort of timeframe are we looking at?
Ha! I mock your assumptions that someone actually has any idea. ;-)
Really, I think everyone is most interested in the last question. How long will the split take? If it's going to happen gradually over several months, what should people who are considering using twisted.web or Nevow do? If it's going to happen in the next two weeks... well, then, it's about time someone stood up and said so!
twisted.web split is going to be tricky, since people are rewriting it at the same time. It will probably be a short while before the split actually occurs, and we're probably going to have to put a bunch of BC code in twisted/web/.
But like I said, people shouldn't worry about using *twisted.web*. It will remain backwards compatible. I can't say anything about the backwards compatibility of all the slightly different APIs in nevow; that's not my concern.
_______________________________________________ Twisted-web mailing list Twisted-web@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
On Tue, Apr 20, 2004 at 02:52:26PM -0700, David Reid wrote:
... 2) Backport some of the nicer parts of the Nevow API (locateChild and child_XXX methods as opposed to getChild, getDefaultChild, getChildWithDefault, etc.) Wether or not the old api will still be ...