On Tue, Sep 11, 2012 at 9:43 AM, <exarkun@twistedmatrix.com> wrote:
On 10:49 am, mithrandi@mithrandi.net wrote:
On Tue, Sep 11, 2012 at 6:05 AM, Glyph <glyph@twistedmatrix.com> wrote:
Such a bug may already exist - if you wouldn't mind, would you search for it, and if you can't find it, file a new one?
I don't know if there's an existing bug or not, but implementing a names() method is problematic. The natural API would be something like names('#foo') -> Deferred firing with a list of names in the channel. The difficulty in implementing this comes from the fact that there are two possible results from issuing a NAMES command on IRC: a serious of zero or more RPL_NAMREPLY messages followed by an RPL_ENDOFNAMES message, *or* any error message the IRC server feels like. There are a number of partial workarounds for this, involving various combinations of queues, timeouts, and unreliable detection of responses, but none of them seem particularly satisfactory to me.
This is the excuse that is always given for not implementing a new feature on `IRCClient`. However, here's another equivalent way of stating the objection:
IRC is a terrible protocol and it is very difficult to implement a method like `names` reliably, due to the various vague and obscure corner cases presented. Therefore, instead of Twisted tackling this problem and providing a single (perhaps imperfect) implementation, every single IRC application developer should instead rediscover this sad reality for themselves and then implement their own uniquely buggy version of this functionality.
I know you know what this means, exarkun, but for those who don't know exactly what this means, it means that you can send two requests out, and not be guaranteed to get replies in any particular order (or at all), and that means that you can get ambiguous replies to requests. Additionally, IRC daemons may play tricks and send out "replies" that doesn't associate with any request you've sent, as a means to have a client perform a specific action; for instance, bouncers usually send join replies without any associated requests method of forcing a client to open a buffer for a particular channel, and certain networks also use this same technique to force users on specific channels all the time (and they will also make a PART request on this particular channel fail). These two things mean that you cannot have a Deferred-based API for IRC, where each request correlates to one response, and instead need to have a reactionary system where you cast a NAMES out to the wind, and just implement some sane behavior on every RPL_NAMREPLY you get, independent of what triggered it.
Hopefully, cast in that light, it's a bit more clear why this might not be a reasonable argument.
I can think of other arguments against adding a `names` (or similar) method to `IRCClient`, but since it's not likely anyone is actually going to step up and do any work on `irc.py` anyway, I don't feel the need to make them (and I'd much rather someone actually maintain `irc.py`).
Jean-Paul
(On the other hand, a method that just sends NAMES #foo without any response handling would be pretty straightforward to implement, maybe that's what you meant?) -- mithrandi, i Ainil en-Balandor, a faer Ambar
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
-- Jasper