[Twisted-Python] Re: IRC Client examples... PLEASE HELP

Glyph Lefkowitz glyph at twistedmatrix.com
Thu Jan 1 10:47:37 EST 2004


On Jan 1, 2004, at 2:22 AM, JD wrote:

> One of my main problems is where to put my code.   Do I put it in the 
> factory class,
> or do I put it in the Client class?   One always points to the other.  
>  I suppose it don't really matter,
> but I'm sure the author(s) of twisted have their OWN ideas of where to 
> put their specific code,
> but they sure don't seem to have been very sucessful in conveying this 
> info to others.

It depends.

The general pattern for Twisted code is to separate protocol logic from 
application logic.  Your protocol subclass should translate from 
protocol-level events (IRCClient.signedOn, in this case) to 
application-level events (like a hypothetical 
'jd.ChatterRobot.nowOnIRCAs(nick)' method).  As for division between 
"protocol" and "factory" - try to make it so that your factory class 
can support multiple connected clients at once.  It should be small.  
Any logic associated with a particular connection should go in the 
protocol class, and any logic associated with all connections 
simultaneously must at least be referenced from the factory class.  
Generally it's a bad idea to put that logic actually into the protocol 
class because that establishes a hard dependency between network code 
and application logic which makes your application logic harder to 
write test cases for.

This pattern breaks down by necessity when dealing with very 
network-heavy code, or abstractions over things that have to logically 
understand IP addresses and the like.   However, try to follow the 
general rule as much as possible even in this kind of code.

The reason that nobody has suggested a particular answer to your 
problem is that the best approach involves keeping your code in an 
organization that best fits your problem domain, and is not dictated by 
Twisted.  As long as the network events make it from the reactor to 
your python objects, there are few constraints as to how to organize 
those objects, and most of those have to do with starting up and 
shutting down cleanly in the context of bin/twistd.

> I know it's mostly due to my lack of knowledge,  but the only part 
> that's really well documented
> is the Twisted Web section.

I know our docs aren't the best, but I think that these cover the 
relevant organization issues:

	http://www.twistedmatrix.com/documents/howto/servers
	http://www.twistedmatrix.com/documents/howto/clients

and they have nothing to do with Twisted Web.

If you disagree, and there is really a particular documentation 
problem, open a doc bug in the tracker 
(http://www.twistedmatrix.com/bugs) and assign it to "hypatia".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20040101/b65ac0eb/attachment.pgp 


More information about the Twisted-Python mailing list