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".