Right. I was thinking about it from too high of a level, I think, and focused too much on a single example, HTTPS. To clarify a couple things, though, I actually didn't mean for transports to populate the state with superfluous information or things they didn't already know. Again, based on the single example I was considering, i was thinking they could intelligently populate it with state they know will be needed, and already have. Like the HTTPS server spawning a new HTTPS transport channel knows the channel will need its SSL information, and the transport can add it's own socket connection to the state in case the protocol needs it. I had also thought the state might somehow end up participating in get_extra_info(), so the expensive information returned was stored there; more importantly, though, I didn't mean for any such calls to be made preemptively in an attempt to populate state just in case a protocol did need it.
HTTPS is a single, atypical example that's too high-level…and something similar to WSGI seemed like a reasonable approach ;-)
Shane Green www.umbrellacode.com 408-692-4666 | firstname.lastname@example.org
On Jan 28, 2013, at 7:45 AM, Guido van Rossum email@example.com wrote:
On Mon, Jan 28, 2013 at 12:57 AM, Shane Green firstname.lastname@example.org wrote:
What about giving the protocol an environ info object that should have all information it needs already, which could (and probably should) include things like the SSL certificate information, and would probably also be where additional info that happened to be looked up, like host name details, was stored and accessed. Assuming the transports, etc., can define all the state information a protocol needs, can operate without hardware dependencies; in case that doesn't happen, though, the state dict will also have references to the socket, so the protocol could get to directly if needed.
Hm. I'm not keen on precomputing all of that, since most protocols won't need it, and the cost add up. This is not WSGI. The protocol has the transport object and can ask it specific questions -- if through a general API, like get_extra_info(key, [default]).
-- --Guido van Rossum (python.org/~guido)