The correct answer is: "nobody knows". But here are some ideas I've been kicking around the ol' cranium lately...
[09:32] *** now talking in #cherrypy [10:22] <Lawouach> where to start [10:22] <Lawouach> what's your basic idea toward 3.0? [10:22] <@fumanchu> oh, I have so many ;) [10:22] <Lawouach> lol [10:22] <Lawouach> say big general ones :) [10:22] <Lawouach> not details per se [10:23] <@fumanchu> 1) make CP have a kick-butt, non-CP-specific toolkit (lib/httptools), that is SO good that Quixote, Django, et al can't *help* but decide to use it instead of their own server processes [10:24] <@fumanchu> even if they don't like the way CP maps handlers to URL's, for example [10:24] <@fumanchu> they should be able to build a server with the behavior they like out of lib/httptools [10:25] <Lawouach> we want to be lib that rule them all :) [10:25] <@fumanchu> yup [10:26] <Lawouach> i agree as long as we don't become a framework on our own, but i already know it's not what you intend :) [10:26] <@fumanchu> right [10:26] <@fumanchu> it's an anti-framework approach [10:26] <@fumanchu> we make writing-a-web-framework into a weekend's work [10:27] <@fumanchu> take some from column A; try all of column B [10:27] <Lawouach> do you want to stay very low-level (aka HTTP wrapper level) or make it a bit higher level and provide functions such as the bast_match() we were talking about last week? [10:27] <@fumanchu> best_match would be fine as long as it doesn't depend upon cherrypy [10:28] <Lawouach> right, this was a bad example [10:28] <Lawouach> but basically where httptools should stop? [10:28] <@fumanchu> I think that can be open-ended [10:28] <Lawouach> i think we should keep the level you've been doing till now [10:29] <@fumanchu> 2) then, by pulling a ton of code out of _cphttptools (putting it in lib/httptools instead), I want to see if we can get the Request and Response objects down to a tiny size [10:34] <@fumanchu> the trunk version of _cphttptools is already 60% of its 2.1 size [10:35] <Lawouach> right. hmmm [10:37] <@fumanchu> and a *lot* of what's left is very OO [10:38] <@fumanchu> so, one idea I'm toying with: allow developers to use their own subclasses of Request and Response [10:40] <@fumanchu> if we make it super-easy to use custom Request subclasses, then they will want to start overriding Request.run [10:40] <@fumanchu> take out the filter logic, and Request.run becomes:
def _run(self, requestLine, headers, rfile): self.headers = list(headers) self.headerMap = httptools.HeaderMap() self.simpleCookie = Cookie.SimpleCookie() self.rfile = rfile self.processRequestLine(requestLine) try: self.processHeaders() self.processBody() self.main() cherrypy.response.finalize() except cherrypy.RequestHandled: pass except (cherrypy.HTTPRedirect, cherrypy.HTTPError), inst: inst.set_response() cherrypy.response.finalize()
[10:40] <Lawouach> regarding the subclassing of request and response, i'm know that it could interest very much the guys behind itools [10:40] <@fumanchu> yes [10:40] <@fumanchu> and Ben Bangert (routes) [10:41] <@fumanchu> anyway, if Request.run is *that* simple, then who needs filters? [10:41] <@fumanchu> just code them procedurally into your Request.run method [10:43] <@fumanchu> looking over the filters that are built in... [10:44] <@fumanchu> I think that half could be done just as easily as lib/httptools functions [10:44] <@fumanchu> and half could be "always on" [10:44] <@fumanchu> (if we continue to improve them, like encodingfilter, to meet the HTP spec) [10:44] <@fumanchu> HTTP [10:44] <Lawouach> that's my white cheap :) (i don't think this expression exists so i make it up!) [10:45] <Lawouach> i really want CP to be HTTP conditionnaly compliant at least :) [10:45] <Lawouach> and maybe in CP 4.0 to be unconditionnaly compliant! [10:45] <Lawouach> :p [10:45] <@fumanchu> I completely agree [10:46] <@fumanchu> anyway, I want to stress that I'm still playing with these ideas [10:46] <@fumanchu> nothing's set in stone [10:47] <Lawouach> since you've be proposing them a while back, i've been a great fan of them [10:47] <@fumanchu> and trying to implement them will turn up lots of problems, I'm sure [10:47] <@fumanchu> oh, well thanks [10:47] <Lawouach> that's why i don't have so many different things to bring for cp 3.0 [10:51] <@fumanchu> one of the nice things about these ideas for 3.0 is that the bulk of the work can be done within the 2.x branch
|<< <||Current||> >>|