<div class="gmail_quote">On Thu, Jul 14, 2011 at 8:48 AM, Tim Allen <span dir="ltr"><<a href="mailto:screwtape@froup.com">screwtape@froup.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Jul 13, 2011 at 02:03:03PM +0200, Laurens Van Houtven wrote:<br>
> So, some of you might remember my async-pep post a while ago. Some people<br>
> correctly complained there was no code or text. There's some code and quite<br>
> a bit of text now. In fact, it even has a PEP number (3153)! So I'm<br>
> soliciting feedback again.<br>
<br>
</div>The idea of Protocols implementing Transports is vaguely gestured at as<br>
a Useful Thing, but not much detail is given. I think it would be useful<br>
for the final PEP to address that topic more rigorously - partially<br>
because it's good to have a firm basis on which to model SOCKS and SSH<br>
libraries, but mostly because figuring out how SSL should interact with<br>
TCP is going to give people headaches. Twisted, so far as I can see,<br>
just sort of punts and says "Yeah, SSL is just another transport like<br>
TCP", but then you have to make the SSL transport support all the same<br>
options that the TCP transport supports (socket options? IPv6?), but<br>
then what if you want to run SSL over a serial port or a SOCKS<br>
connection... AAAAAAAAAAAAA!<br>
<br>
In practice, it might be simpler because "SSL" means "whatever subset of<br>
TCP functionality we can coax OpenSSL into providing" rather than<br>
a fully stackable protocol-providing-a-transport.<br></blockquote><div><br><br>Cool. Can I shove those 2 paragraphs into a ticket or will the copyright monster haunt me?<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
The thing with Consumers and Producers seems... very abstract. If I'm<br>
sitting down to retrieve email via POP3 (to pick a random protocol),<br>
'transports' and 'protocols' are tools that nestle very comfortably in<br>
my mental model of the task in front of me; "consumers" and "producers"<br>
are not. Are they concepts that should be handled by transport<br>
implementors? Protocol implementors? Protocol users? Should they be<br>
mapped onto XON/XOFF or RTS/CTS by serial transports?<br></blockquote><div><br>Yes, Consumers and Producers are about flow control, and most Transports probably are producers.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
At least in Twisted, transports and protocols do not exist in a vacuum;<br>
they have to be hooked up via the reactor. Will this PEP define<br>
a (skeletal) API to be implemented by potential reactors, or is that<br>
going to left entirely unspecified, like WSGI?<br></blockquote><div><br>Entirely unspecified, because different implementations have to do pretty different things.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
_______________________________________________<br>
Twisted-Python mailing list<br>
<a href="mailto:Twisted-Python@twistedmatrix.com">Twisted-Python@twistedmatrix.com</a><br>
<a href="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python" target="_blank">http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>cheers<div>lvh</div><br>