[Twisted-Python] Async-pep (again)

[Glyph Lefkowitz]

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.