On 07:30 pm, nas@arctrix.com wrote:
Chris McDonough <chrism@plope.com> wrote:
As far as I can tell, asyncore/asynchat is all "undocumented internals". Any use of asyncore in anger will use internals; there never was any well-understood API to these modules.
The implementation requires some intricate and platform specific code which is why it would be nice to be a standard library feature.
I'm sure that Twisted has the necessary parts but the problem, IMHO, is that it does so much more else.
... which is exactly why I have volunteered to explain to someone how to separate the core event-loop bits (suitable for inclusion in the standard library) from the huge pile of protocol implementations which are not necessarily useful. Despite the FUD to the contrary, Twisted's internal factoring is quite good; it's not a single, undifferentiated pile of code. Plus, at this point, we're not even talking about actually putting any Twisted code into the standard library, just standardizing the "protocol" API, which basically boils down to: connectionMade() -> your connection has begun dataReceived(data) -> you got some bytes, handle them connectionLost(reason) -> your connection has gone away (with an object explaining why) and the inverse, "transport", which is: write(data) -> deliver some data to the dataReceived on the other end of this connection (non-blocking, with buffering) loseConnection() -> goodbye There are a few other minor details related to how you set these up to talk to each other and tell when the out-buffer is empty, but it's all pretty straightforward. The main point is that you don't ever call recv() or send() and deal with buffering or handling weird errno values. For example, if your connection goes away, the notification you get is "your connection went away", not "oops you tried to read some bytes, but your connection was gone by the time you tried, even though I just told you it was ready for reading" or other similarly obtuse failure modes.