Le dimanche 27 janvier 2013 à 14:12 +0200, Yuval Greenfield a écrit :
On Sun, Jan 27, 2013 at 1:21 PM, Antoine Pitrou solipsis@pitrou.net wrote:
> Most protocols should be written independent of transport.
But it seems to
> me that a user might write an entire app as a "protocol".
Well, such an assumption can fall flat. For example,
certificate
checking in HTTPS expects that the transport is some version
of TLS or
SSL: http://tools.ietf.org/html/rfc2818.html#section-3.1
I'm not sure I understood your reply. You'd be for an api that exposes the underlying transport? I meant to say that "an entire app" entails control over the subtleties of the underlying transport.
What I meant is that the HTTP protocol needs to know that it is running over a secure transport, and it needs to fetch the server certificate from that transport (or, alternatively, it needs to have one of its callbacks called by the transport when the certificate is known). That's not entirely transport-agnostic.
Regards
Antoine.
On Sun, Jan 27, 2013 at 4:16 AM, Antoine Pitrou solipsis@pitrou.net wrote:
Le dimanche 27 janvier 2013 à 14:12 +0200, Yuval Greenfield a écrit :
On Sun, Jan 27, 2013 at 1:21 PM, Antoine Pitrou solipsis@pitrou.net wrote:
> Most protocols should be written independent of transport.
But it seems to
> me that a user might write an entire app as a "protocol".
Well, such an assumption can fall flat. For example,
certificate
checking in HTTPS expects that the transport is some version
of TLS or
SSL: http://tools.ietf.org/html/rfc2818.html#section-3.1
I'm not sure I understood your reply. You'd be for an api that exposes the underlying transport? I meant to say that "an entire app" entails control over the subtleties of the underlying transport.
What I meant is that the HTTP protocol needs to know that it is running over a secure transport, and it needs to fetch the server certificate from that transport (or, alternatively, it needs to have one of its callbacks called by the transport when the certificate is known). That's not entirely transport-agnostic.
Yeah, it sounds like in the end having access to the socket itself (if there is one) may be necessary. I suppose there are a number of different ways to handle that specific use case, but it seems clear that we can't anticipate all use cases. I'd rather have a simpler abstraction with an escape hatch than attempting to codify more use cases into the abstraction. We can always iterate on the design after Python 3.4, if there's a useful generalization we didn't anticipate.
-- --Guido van Rossum (python.org/~guido)
On Jan 27, 2013, at 8:28 AM, Guido van Rossum guido@python.org wrote:
On Sun, Jan 27, 2013 at 4:16 AM, Antoine Pitrou solipsis@pitrou.net wrote:
Le dimanche 27 janvier 2013 à 14:12 +0200, Yuval Greenfield a écrit :
On Sun, Jan 27, 2013 at 1:21 PM, Antoine Pitrou solipsis@pitrou.net wrote:
Most protocols should be written independent of transport. But it seems to me that a user might write an entire app as a "protocol".
Well, such an assumption can fall flat. For example,
certificate
checking in HTTPS expects that the transport is some version
of TLS or
SSL: http://tools.ietf.org/html/rfc2818.html#section-3.1
I'm not sure I understood your reply. You'd be for an api that exposes the underlying transport? I meant to say that "an entire app" entails control over the subtleties of the underlying transport.
What I meant is that the HTTP protocol needs to know that it is running over a secure transport, and it needs to fetch the server certificate from that transport (or, alternatively, it needs to have one of its callbacks called by the transport when the certificate is known). That's not entirely transport-agnostic.
Yeah, it sounds like in the end having access to the socket itself (if there is one) may be necessary. I suppose there are a number of different ways to handle that specific use case, but it seems clear that we can't anticipate all use cases. I'd rather have a simpler abstraction with an escape hatch than attempting to codify more use cases into the abstraction. We can always iterate on the design after Python 3.4, if there's a useful generalization we didn't anticipate.
-- --Guido van Rossum (python.org/~guido)
Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
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.
On Mon, Jan 28, 2013 at 12:57 AM, Shane Green shane@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 get_extra_info(key, [default]).
-- --Guido van Rossum (python.org/~guido)
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@umbrellacode.com
On Jan 28, 2013, at 7:45 AM, Guido van Rossum guido@python.org wrote:
On Mon, Jan 28, 2013 at 12:57 AM, Shane Green shane@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 get_extra_info(key, [default]).
-- --Guido van Rossum (python.org/~guido)
On Mon, Jan 28, 2013 at 5:45 PM, Guido van Rossum guido@python.org wrote:
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]).
I forgot to ask before, but why is get_extra_info better than normal attributes and methods?
val = transport.get_extra_info(key, None) if val is None: pass
# vs
if hasattr(transport, key): val = transport.key else: pass
Yuval
On Thu, Jan 31, 2013 at 12:52 AM, Yuval Greenfield ubershmekel@gmail.com wrote:
val =
getattr(transport, key)
You probably meant
val = getattr(transport, "key", None)
Your original example also forgot the quotes around "key" in the hasattr() call.) The number of attempts needed to get your example right tells me this is not a good proposal. :-)
-- --Guido van Rossum (python.org/~guido)
On Thu, Jan 31, 2013 at 12:51 AM, Yuval Greenfield ubershmekel@gmail.com wrote:
On Mon, Jan 28, 2013 at 5:45 PM, Guido van Rossum guido@python.org wrote: >
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]).
I forgot to ask before, but why is get_extra_info better than normal attributes and methods?
val = transport.get_extra_info(key, None) if val is None: pass
# vs
if hasattr(transport, key): val = transport.key else: pass
hasattr() smells bad. It also has namespace issues (hasattr(transport, "write") returns true) and if people forget to use it (perhaps because the transport they normally use always has a certain attribute) their code is brittle. Defining a new API with a string key signals clearly that the value may or may not exist, and reminds people to test the result for None. (Of course they can forget that too. But it still feels different to me.)
-- --Guido van Rossum (python.org/~guido)
On Fri, Feb 1, 2013 at 3:58 AM, Guido van Rossum guido@python.org wrote:
hasattr() smells bad. It also has namespace issues (hasattr(transport, "write") returns true) and if people forget to use it (perhaps because the transport they normally use always has a certain attribute) their code is brittle. Defining a new API with a string key signals clearly that the value may or may not exist, and reminds people to test the result for None. (Of course they can forget that too. But it still feels different to me.)
I understand. It's a good solution for clearly separating the standard transport api from the extra-and-specific api. We want to make it obvious when a protocol is breaking the transport abstraction - to promote playing nicely with different transports.
-
Antoine Pitrou -
Guido van Rossum -
Shane Green -
Yuval Greenfield