[Twisted-Python] IRC protocol rewrite?

[Glyph Lefkowitz]

On Wed, 2002-01-02 at 11:46, Ivo van der Wijk wrote:
> Hi All,
> 
> I'm currently investigating the IRC Protocol as implemented by twisted,
> to see if I perhaps can use it in my irc client, or if it perhaps can
> use code from my irc protocol parsing.
> 
> 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?)
> 
> 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.

This is an intentional design failure :).

The feature-set of IRC is highly idiosyncratic, and difficult to
represent in terms of "real" abstractions -- for example, the notion of
a "modeless" channel doesn't particularly make sense outside of the
world of IRC's implementation; there are no gradations between "modeful"
and "modeless" channels, unless you have a Services implementation w/
ChanServ and mode lock.  "local" channels don't either, considering that
they are really just a way to introduce an artificial barrier between
servers.  The whole point of the R in IRC is to avoid that :)

I have to agree that for the client, it's probably a bad idea to enforce
restrictions like that, since it's designed to connect to other IRC
servers, and be generally useful to connect to external services which
may be set up in bizarre configurations.

On the server, however, I would like to drop support for as many IRCisms
as reasonably possible, so that we can implement a richer set of
functionality; probably through the "services" idiom, since that allows
for fairly arbitrary specification of inputs (as opposed to the limited
set of client-understood modes that one may specify, and the 26
allowable characters).

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

I disagree.  IRC is a poorly specified protocol in its RFC, so the
"usual" extensions are a part of any reasonable IRC implementation these
days.  Unless you can come up with a requirement for functionality that
would require them being in different classes, I think they should stay
where they are.

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

Whoops.  That definitely sounds like it needs to be fixed :)

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

Certainly discussable, especially since the IRC support is not as good
as it could be.  If you replace it with something non-API-compatible,
I'd like to hear from the authors of code that this would break, and
certainly refactor any code currently in Twisted to work the new way.

-- 
______      you are in a maze of twisted little applications, all
|   |_\     remarkably consistent.
|     |          -- glyph lefkowitz, glyph @ twisted matrix . com
|_____|             http://www.twistedmatrix.com/