[Twisted-Python] implementing NAMES in IRC

Tristan Seligmann mithrandi at mithrandi.net
Tue Sep 11 20:29:47 EDT 2012


On Wed, Sep 12, 2012 at 2:12 AM, Adrian Overbury <skaarjj at gmail.com> wrote:
> 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.

Handling RPL_NAMREPLY/RPL_ENDOFNAMES responses in order to update a
list of users is perfectly feasible (most user-interactive IRC clients
do something of this nature); the problem is directly associating a
response with a request. If you send NAMES #code, there are three
possibilities: 1) the ircd sends you a sequence of
RPL_NAMREPLY/RPL_ENDOFNAMES with the list of users, 2) you get an
error response, 3) nothing happens. While 3) is unlikely, there's no
particular reason an ircd couldn't behave that way (I don't
specifically know of one, but in general, the IRC protocol and ircds
are written and designed with primarily the interactive use case in
mind, not automated agents). However, the real fly in the ointment is
2); there is no way to know what errors might be returned in response
to a NAMES message, and many of those responses will not even mention
the channel name, thus giving you no way to recognize that the request
will never "complete". If you're keeping a deferred around to fire
with the response, then unless something else intervenes (a
cancellation timer?), the deferred will just hang around, which also
means keeping its callbacks and the objects they reference alive.

Thus, the problem is not with tracking the users in a channel in
general (although there are issues with tracking the channel modes of
those users...), but rather with specifically implementing an API like
names(channel) -> Deferred firing with a list of names. If you're
willing to accept an arbitrary timeout and use that as the only (or at
least the primary) mechanism of failure detection, as well as a few
other compromises (in the area of "overlapping" requests for the same
channel), it would be possible, I just don't feel that the base
IRCClient class is the right place to implement things like this, and
I'd also discourage designing IRC clients (whether they are bots or
user-interactive clients) in a way that requires such an API.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar



More information about the Twisted-Python mailing list