[Twisted-Python] Async-pep (again)
Glyph Lefkowitz
glyph at twistedmatrix.com
Thu Jul 14 17:28:03 MDT 2011
On Jul 14, 2011, at 2:48 AM, Tim Allen wrote:
> On Wed, Jul 13, 2011 at 02:03:03PM +0200, Laurens Van Houtven wrote:
>> So, some of you might remember my async-pep post a while ago. Some people
>> correctly complained there was no code or text. There's some code and quite
>> a bit of text now. In fact, it even has a PEP number (3153)! So I'm
>> soliciting feedback again.
>
> The idea of Protocols implementing Transports is vaguely gestured at as
> a Useful Thing, but not much detail is given. I think it would be useful
> for the final PEP to address that topic more rigorously - partially
> because it's good to have a firm basis on which to model SOCKS and SSH
> libraries, but mostly because figuring out how SSL should interact with
> TCP is going to give people headaches. Twisted, so far as I can see,
> just sort of punts and says "Yeah, SSL is just another transport like
> TCP", but then you have to make the SSL transport support all the same
> options that the TCP transport supports (socket options? IPv6?), but
> then what if you want to run SSL over a serial port or a SOCKS
> connection... AAAAAAAAAAAAA!
> In practice, it might be simpler because "SSL" means "whatever subset of
> TCP functionality we can coax OpenSSL into providing" rather than
> a fully stackable protocol-providing-a-transport.
Actually, you might be interested in <http://tm.tl/4854>. This will be in 11.1. TLS _is_ a protocol-that-is-a-transport now (in trunk). This was the case in 11.0, too, but only for the IOCP reactor. We've been smoothing out some interesting quirks that occurred as a result, mostly test-related, but it's looking good for the release; more robust, actually, because it's easier to test the stacked version than to try to trick sockets into returning specific values in C.
> The thing with Consumers and Producers seems... very abstract. If I'm
> sitting down to retrieve email via POP3 (to pick a random protocol),
> 'transports' and 'protocols' are tools that nestle very comfortably in
> my mental model of the task in front of me; "consumers" and "producers"
> are not.
The APIs definitely aren't as nice, and that's where I predict the most discussion in the PEP.
> Are they concepts that should be handled by transport implementors?
Yes, pretty much always.
> Protocol implementors?
Yes, if you need them.
> Protocol users?
It depends. Ideally you should be able to rely on the protocol providing a reasonable stream-friendly API. (You probably only care about this if you're writing a proxy.)
> Should they be mapped onto XON/XOFF or RTS/CTS by serial transports?
Either or. Probably an option to the serial transport.
More information about the Twisted-Python
mailing list