On Thu, Mar 5, 2009 at 3:11 PM, <gl...@divmod.com> wrote: > > On 07:30 pm, n...@arctrix.com wrote: >> >> Chris McDonough <chr...@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.
Those "obtuse failure modes" are handled fairly well by asynchat. It works pretty well, and includes sample implementations to get you 99% of the way towards the 5-method API you describe (which is why a lot of people use asynchat instead of asyncore). If it weren't for the fact that asynchat had a previously existing API (including the .push(), collect_incoming_data(), and found_terminator()), I think it could stand for methods to make it fit better with asyncore's handle_*() methods. - Josiah _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
