[Twisted-Python] IRC protocol rewrite?

Kevin Turner acapnotic at twistedmatrix.com
Wed Jan 2 17:38:00 EST 2002

On Wed, 2002-01-02 at 09:46, Ivo van der Wijk wrote:
> However, I noticed some bugs and (imho) design failures in the current
> implementation, which makes the code not very usefull for any other 
> use than what it's currently used for (twisted irc client + server?)

(And Tendril.  Don't forget Tendril, in twisted.words.tendril.)
I'm interested in hearing what makes it "not very useful" though.  I
didn't really get a sense of that from your message.

> For example, channels are hardcoded as starting with '#', i.e.
> IRCClient.join prepends a '#' to the channelname. Hoewever, most servers
> support alernative style channels such as &channel (local channels),
> +channel (modeless channels), and perhaps more.

Valid point.  Of course, nobody actually uses those in real life
anymore, but it'd be fine to support it in the interest of completeness.

> Furthermore, IMHO, the IRCClient class implements too many protocols
> in one class. IRC, CTCP and DCC are distinct protocols, and each belong
> in their own class.

There's some sense to this too.  As a Protocol class, IRCClient is
overfeatured (as a "client", maybe it's okay).  I'm not quite sure how
to split off the CTCP stuff though, as intertwined as the CTCP messages
are with IRC.  Would you define IRCClient not only as a Protocol, but as
a Transport for CTCP?  Eaugh...  A somewhat more mundane option would be
to just put all the ctcp* methods in a mixin class.  That might make the
organization a little tidier, but it wouldn't change the interface at
all, so I'm not sure if that would satisfy your concerns or not.

As for DCC, it's in seperate protocol classes already.

> Lastly, the current parsemsg routine can't handle ipv6 addresses in certain 
> replies, i.e. a 311 (whois) reply like:
> :irc.xs4all.nl 311 VladDrac [p] -patrick 3ffe:2500:900:2000:1337:1337:1337:1337 *:foo
> will be parsed incorrectly. I may provide a patch for this later.

Eh?  It's not immediately obvious to me what will break.  But patches
are always fine.  =)

> Is replacing the current IRC protocol with a (non-api-compatible) new
> protocol discussable? If so, I'll make some suggestions on how I would
> implement the protocol.

IMO, speaking as the guy who's probably spent the most time with it,
it's certainly discussable.  Unless there was some message I didn't read
from the BDFL about an API freeze. ;)  

"Oh no, it's a trap!"-ly,

 - Kevin (Acapnotic)

The moon is waning gibbous, 86.8% illuminated, 18.3 days old.

More information about the Twisted-Python mailing list