[Twisted-Python] Re: IRCClient
radix at twistedmatrix.com
Wed Feb 19 19:53:58 EST 2003
On Wed, Feb 19, 2003 at 01:14:02PM -0500, Konrad Rokicki wrote:
> On 18 Feb 2003, Kevin Turner wrote:
> > What would you have them do? The protocol does not dictate any response
> > to these messages, and protocols.irc.IRCClient is intended to be an
> > implementation of just the IRC client protocol. The class is designed
> > to be extensible so its users can subclass it and define their own
> > irc_QUIT and irc_RPL_NAMREPLY methods. The decision of what to do when
> > you receive such a message is up to the application, I think.
> I don't mean the client needs to respond to the messages. But why doesn't
> it process a QUIT the same way it processes a JOIN or PART? The irc_QUIT
> method could be implemented to parse the message and call userQuit.
> The same goes for the NAMREPLY stuff except you'd also need a method
> to request the names list. Sure, I could implement all this in my
> subclass but wouldn't it be cleaner to hide all this protocol stuff inside
> the protocol? That way my subclass would not need to know how to parse a
> QUIT message.
Kevin, Jp and I discussed this on IRC a little bit, and came to the
conclusion (well, they stopped arguing against me, anyway ...) that
there should be more IRC-specific abstractions developed. There was
some uneasiness about putting more of them in IRCClient,
though. Perhaps we should split off another class that has
higher-level stuff like NAMES handlers.
Twisted | Christopher Armstrong: International Man of Twistery
Radix | Release Manager, Twisted Project
More information about the Twisted-Python