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. _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
