[Twisted-Python] IRC protocol rewrite?
Ivo van der Wijk
ivo at amaze.nl
Wed Jan 2 18:18:34 EST 2002
On Wed, Jan 02, 2002 at 02:38:00PM -0800, Kevin Turner wrote:
> 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.
The current implementation is rather specific. For example, it assumes
only #-like channels exist, it takes actions/decisions the client builder
would rather like to implement (i.e. irc_ERR_NICKNAMEINUSE will generate
a new nickname by appending a _ - who says I want this in my client?),
ctcp_PING immediately sends a ping reply - this won't work with my
ignore list, etc.
I'm not saying this is wrong behaviour, it just does not belong at this
level in the protocol. I just want a basic abstraction of the server
connecting/disconnecting, server messages receiving (dispatching) and
sending. Anything else should be implemented in a derived/separate class.
> > 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.
IRCops tend to visit channels like &ERRORS and &NOTICES (at least ircnet
supports this) to view server messages. Besides, you simply don't adhere to
the 'protocol' (eventhough it's poorly documented). And we have MIRC for
that, right? :)
> > 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.
The name IRCClient is a bit misleading, but the basic IRC protocol *is*
the transport for CTCP! CTCP is a separate protocol encoded in ^A's in
PRIVMSG/NOTICE. Also, CTCP is way less documented than the irc protocol,
and clients are (somewhat) free to make their own CTCP extension (i.e.
you coud send whiteboard drawing commands over ctcp or communicate
gameplay over ctcp over irc. Some clients (zircon?) actually do this)
> As for DCC, it's in seperate protocol classes already.
There's is quite some DCC support in the IRCClient class that I have here
(twisted 0.12.3), i.e. ctcpQuery_DCC which initiates DCC, maintains a list
of sessions, etc
> > 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. =)
>>> parsemsg(":irc.xs4all.nl 311 VladDrac [p] -patrick 3ffe:2500:900:2000:1337:1337:1337:1337 *:foo")
('irc.xs4all.nl', '311', ['VladDrac', '[p]', '-patrick', '3ffe', '2500:900:2000:1337:1337:1337:1337 *:foo'])
It's the assumption that a ':' will start the remainder of the argument
list, which is not true if one of the arguments is a ipv6 address.
> > 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. ;)
Drs. I.R. van der Wijk -=-
Brouwersgracht 132 Amaze Internet Services V.O.F.
1013 HA Amsterdam, NL -=-
Tel: +31-20-4688336 Linux/Web/Zope/SQL/MMBase
Fax: +31-20-4688337 Network Solutions
Web: http://www.amaze.nl/ Consultancy
Email: ivo at amaze.nl -=-
More information about the Twisted-Python