Comment 3 for bug 900792

Thanks. I'm not sure about this patch, at least the documentation part. It suggests that the read and write ends of the connection can actually be shut down separately, but they cannot be. At the very least, I would want to see the documentation for this change point out that the *how* parameter is completely ignored, and only present for compatibility with the normal socket interface. Perhaps even better would be to raise an exception on SHUT_RD and SHUT_WR and only allow SHUT_RDWR. However, this would still break SocketServer, which tries to SHUT_WR.

I wish I could suggest another change that seemed to have less chance to introduce confusion, but this seems like a sticky issue. The whole notion of transparently pretending that an SSL connection is identical to a TCP connection is half-baked. Even beyond that, trying to do it with a single API (ie, using Connection as both the nice, featureful SSL connection object *and* the pretend-to-be-TCP object) just makes matters worse. Perhaps the right direction to go in is to try splitting the TCP compatibility object off so it no longer gets mixed up with the SSL object.

Unit tests for the change are also necessary before it can go into trunk.

Thanks again.