On Nov 10, 2004, at 2:36 AM, Martin v. Löwis wrote: > I fail to see the problem. If the file object is replaced/rewrapped > into a SSL object, the base class can continue to use > read/write/send/recv - if only the SSL object supported the same > operations (which it really should if switching from plain sockets > to SSL sockets is a common task) (and you seem to be suggesting that > as a good strategy). It can't work completely transparently; SSL has some more complicated requirements. I don't think it's really useful to go into SSL's inner workings here, but, a major issue is that reading from a socket can sometimes require writing to it and vice versa. > My point here is that you just cannot use the very same class for > SMTP, and SMTP+STARTTLS - you indicated that a subclass must be > created. This was my original point: you cannot instantiate the > baseclass for use with TLS, as the baseclass does not implement > the cmd_STARTTLS method. False. STARTTLS is part of the SMTP protocol and is always implemented, as shown in JP's message. Therefore, there is no subclass, STARTTLS is part of the main SMTP class. But, the real point is that you can use the same class for SMTP and SMTP-over-ssl, which is fortunate, because you need to switch to the over-ssl implementation half way through the connection. This discussion really seems useless to me. Asyncore certainly has some serious deficiencies, and arguing each and every one of them is okay because alternatively "nobody needs that feature" or "If X worked in some way (which it doesn't), then everything would be fine" just seems silly. I've only started developing with Twisted fairly recently, so I don't know the entire history of its development, but I'm pretty sure it wasn't started just for fun... James
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4