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 ;-)
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
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)