[Python-ideas] PEP 3156: getting the socket or peer name from the transport (original) (raw)
Shane Green shane at umbrellacode.com
Tue Jan 29 10:21:17 CET 2013
- Previous message: [Python-ideas] PEP 3156: getting the socket or peer name from the transport
- Next message: [Python-ideas] PEP 3156: getting the socket or peer name from the transport
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 | shane at umbrellacode.com
On Jan 28, 2013, at 7:45 AM, Guido van Rossum <guido at python.org> wrote:
On Mon, Jan 28, 2013 at 12:57 AM, Shane Green <shane at umbrellacode.com> 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 getextrainfo(key, [default]). -- --Guido van Rossum (python.org/~guido)
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130129/fccbc496/attachment.html>
- Previous message: [Python-ideas] PEP 3156: getting the socket or peer name from the transport
- Next message: [Python-ideas] PEP 3156: getting the socket or peer name from the transport
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]