[Python-ideas] PEP 3156 - Asynchronous IO Support Rebooted

[Markus]

Hi,

On Sun, Jan 6, 2013 at 5:25 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 6 Jan 2013 16:45:52 +0100
> Markus <nepenthesdev at gmail.com> wrote:
>>
>> Right, for ssl bios pyopenssl is required - or ctypes.
>
> Or a patch to Python 3.4.
> See http://docs.python.org/devguide/

Or discuss merging pyopenssl.

> By the way, how does "SSL as a protocol" deal with SNI? How does the
> HTTP layer tell the SSL layer which servername to indicate?
SSL_set_tlsext_host_name

> Or, on the server-side, how would the SSL layer invoke the HTTP layer's
> servername callback?

callback - set via
SSL_CTX_set_tlsext_servername_callback
SSL_CTX_set_tlsext_servername_arg


> I would rather have connection_failed(self, exc).
> (where exc can be a OSError or a socket.timeout)

I'd prefer a single callback per error, allows to preserve defaults
for certain cases when inheriting from Protocol.

>> You never know how much data you'll receive, you never know how much
>> data you need for a message, so the Protocol needs a buffer.
>> Having this io in buffer in the Transports allows every Protocol to
>> benefit, they try to read a message from the data passed to
>> data_received(), if the data received is not sufficient to create a
>> full message, they need to buffer it and wait for more data.
>
> Another solution for every Protocol to benefit is to provide a bunch of
> base Protocol implementations, as Twisted does: LineReceiver, etc.

In case your Protocol.data_received gets called until there is nothing
left or 0 is returned, the LineReceiver is simply looking for an \0 or
\n in the data, process this line and return the length of the line or
0 in case there is no line terminatior.

> Your proposed solution (returning the number of consumed bytes) implies
> a lot of slicing and concatenation of immutable bytes objects inside
> the Transport, which may be quite inefficient.

Yes - but is has to be done anyway, so it's just a matter of having
this problem in stdlib, where it is easy to improve for everybody, or
everybody else has to come up with his own implementation as part of
Protocol.

I'd prefer to have this in Transport therefore - having everybody
benefit from any improvement for free.

Markus