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.