Glyph, On Thu, Nov 17, 2005 at 06:57:11AM -0500, glyph@divmod.com wrote: | Do we have a list of use-cases somewhere that detail what "per-request | data" is really a requirement? Most places I've seen the context | actually *used* in this manner it has been a disaster... The system that I've layered over Twisted that I'm now porting to web2 is a request re-write system. Basically, I view request handling as a series of stages which _alter_ the request (I don't particularly like the special status given to path segments in web2, btw; this should be much higher-level logic). For example: 1. I have one stage that converts /k=v/ path segments into cookie entries, so that user agents lacking a good cookie mechansim can still use the parts of my application that require "context" handling. 2. I have another stage that simply looks for a in-memory session object, and attaches it to the request (for further down-stream stages). 3. My next stage does authentication; if a session object is already marked authorized, this step is a no-op. Otherwise, it handles one of many authentication protocols. 4. My application has many many ways to ask for the same thing, so my next stage simply 'canonicalizes' the request. This replaces various short-cuts in the request's path segments or arguments with more tedious but explicit request. 5. Following is an 'authorization' step; which verifies that the current identity is allowed to perform the activity expressed by the (now canonicalized) request. 6. At this point; depending on many factors, my processing tree has many branches -- but at all stages, I'm passing around a request that is being continually modified to reflect the status of the request and where it goes next. I use a state-transition graph to make sure that my request gets in the correct queue. So, this is what I mean by per-request state. Since each stage of execution happens by a distinct Resource, a great deal of information needs to be stored in the Request object (or what ever you want to call it). Now if a ClarkRequest extends a HttpRequest to add what I need, so be it; right now my code is sloppy -- I just modify the request object's dict. Perhaps it is poor pratice; but with a decent regression test it really isn't a problem at all. I only have a handful of variables that are needed. Anyway Glyph, I'm not quite certain I understand what you're saying or recommending. If you could detail a bit more, it would be wonderful. | >I'm personally against polluting the request and response interfaces | >with this kind of stuff, in my opinion cookies are just headers, they | >shouldn't be special. I wouldn't be opposed to higher level cookie | >management that presented a similar interface to both the client and the | >server developer, but I probably won't have any interest in writing | >it. You got to put it this stuff somewhere. An adapter is quite a kludgy, but I guess workable. The current solution, however, is ugly. | Pragmatically speaking cookies are not an "optional" extension to HTTP/1.1. Hear! Hear! Clark