[Twisted-Python] implementing NAMES in IRC

[Adrian Overbury]

On 12/09/2012, at 8:01 AM, "Jasper St. Pierre" <jstpierre at mecheye.net> wrote:

> 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.
> 

However it is entirely possible to sanely parse and store replies in a reactionary system because the first component of an RPL_NAMREPLY message is the name of the channel it applies to.  

You can log or quietly drop replies that aren't for channels you're currently following, and use the others to build out some kind of structure that maintains an active list of users in that channel and their status (maintained through subsequent joins and parts).  Is this not so?  It doesn't sound that complicated to me.

>> 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
> 
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python