[Twisted-Python] implementing NAMES in IRC

Jasper St. Pierre jstpierre at mecheye.net
Tue Sep 11 18:01:31 EDT 2012


On Tue, Sep 11, 2012 at 9:43 AM,  <exarkun at twistedmatrix.com> wrote:
> On 10:49 am, mithrandi at mithrandi.net wrote:
>>On Tue, Sep 11, 2012 at 6:05 AM, Glyph <glyph at 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 at twistedmatrix.com
>>http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python



-- 
  Jasper



More information about the Twisted-Python mailing list