[Twisted-Python] Async-pep (again)

Laurens Van Houtven _ at lvh.cc
Thu Jul 14 02:05:00 MDT 2011

On Thu, Jul 14, 2011 at 8:48 AM, Tim Allen <screwtape at froup.com> 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.

Cool. Can I shove those 2 paragraphs into a ticket or will the copyright
monster haunt me?

> 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. Are they concepts that should be handled by transport
> implementors? Protocol implementors? Protocol users? Should they be
> mapped onto XON/XOFF or RTS/CTS by serial transports?

Yes, Consumers and Producers are about flow control, and most Transports
probably are producers.

> At least in Twisted, transports and protocols do not exist in a vacuum;
> they have to be hooked up via the reactor. Will this PEP define
> a (skeletal) API to be implemented by potential reactors, or is that
> going to left entirely unspecified, like WSGI?

Entirely unspecified, because different implementations have to do pretty
different things.

> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20110714/6216150e/attachment.html>

More information about the Twisted-Python mailing list