[Twisted-Python] IRC protocol rewrite?

Ivo van der Wijk ivo at amaze.nl
Thu Jan 3 08:34:35 EST 2002

On Wed, Jan 02, 2002 at 04:11:34PM -0800, Kevin Turner wrote:
> On Wed, 2002-01-02 at 15:18, Ivo van der Wijk wrote:
> > 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.
> Ah, this is the information I was looking for.  (The bit about
> supporting & channels is a minor detail, worth fixing but not  grounds
> for reimplementation.)  In reply, let me just say that subclassing is a
> wonderful and powerful thing.  You are invited, encouraged even, to
> override any methods which don't do what you want in your subclass. 
> Default implementations are provided in the base class for things like
> irc_ERR_NICKNAMEINUSE because every IRC client needs to have *some*
> implementation of them, or else it will likely be so broken that it
> won't be able to sign on.  But again, don't hesitate to override the
> default methods with something else.  This class uses the
> """getattr(self, "prefix_%s" % command)()""" idiom, so you can always
> add methods for more IRC or CTCP message types (i.e. Zircon extensions)
> in your subclass too.

Well, sure, I can override anything. But in this specific case I'd have
to override so much (and stick with redundant unused code), that I'd rather
re-implement things.

Proposal: I will implement the protocol the way I see it for my irc client,
somewhat based on the current code / the twisted philosophy (my client
needs a rewrite in that area anyway), and if others think my code is 
leaner/better/whatever than the current, we may consider replacing the
current irc protocol with it.

> > 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
> That's because it's a CTCP query which initiates the DCC connection. 
> The DCC connection itself (as opposed to things talking about DCC
> connections) has its own class and instance.

IMHO, this would be like an IP layer building (and maintaining) TCP sessions. 
>From the purists point of view, if I want the basic irc protocol (i.e. for 
some web messaging interface), I would have the redundant ctcp, dcc etc code 
as well. Sure, having it lingering and not using it around won't break 
anything, but the nice thing about OO is that you can encapsulate specific 
functionality into objects, extend them with extra (higher-level) features, 

> As for maintaining a list of sessions, I think that this does belong in
> a "client" implementation, but I agree that this is not state that a
> "protocol" class should be concerned with.  It's only there because I
> couldn't see another way for a subclass to figure out which DCC sessions
> were created, which is something you probably want to know for your
> interface.  Perhaps the default ctcpQuery_DCC method should pass back
> the DCC session as its return value?

That would be better, yes.



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 mailing list