`ITLSTransport` is a bad interface

New submission from exarkun <[email protected]>:

We should come up with something better, for a variety of reasons:

  1. The name is confusing.  There is also `ISSLTransport`.  The relationship of `ITLSTransport` to `ISSLTransport` is that calling `ITLSTransport.startTLS`, if successful, causes the transport to stop providing `ITLSTransport` and start providing `ISSLTransport`.  `TLS` vs `SSL` in no way suggests this.
  1. The behavior of the `startTLS` method is hard to implement.  Mutating an existing transport object is challenging; none of the transport implementations in Twisted facilitate this. (Go look at them if you want to be grossed out.)
    1. The way posixbase implements `ITLSTransport` is to have the transport replace its `__class__` with a dynamically created new one.
    1. The way iocpreactor implements `ITLSTransport` (because setting `__class__` is gross) is by inserting conditionals in the methods which change behavior depending on whether TLS has been started or not, and creating another transport object which jumps over these implementations when necessary.
  1. The distinction between TLS and non-TLS at the application level is blurred, since the same transport object is used for both.

Another point is that there is no way to shut down TLS and begin to use the underlying transport without encryption.  This could be remedied in the current implementation by adding a new method to `ISSLTransport`, but a simpler implementation would be for starting TLS to create a new transport and then for that transport to be discarded after TLS is shut down (and for the application to return to using the original).



----------
Type     : defect
Component: core
Keywords : 
Priority : normal
Nosy     : 
----------
http://twistedmatrix.com/trac/ticket/3821