On Thu, Jul 14, 2011 at 8:48 AM, Tim Allen <screwt...@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@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python > -- cheers lvh
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python