[Twisted-Python] Arbitrary Port/Connector objects
So far there are a couple use-cases for listening and connecting with IListeningPort/IConnector implementers that aren't in twisted.internet. Tv's SRV connector is one, IPv6 sockets is another. Currently it is cumbersome to use these, both because there are no convenience methods in reactor, and because if you want them to serialize properly you have to handle storing and restarting them yourself. Attached patch adds two methods to Application and two methods to the default reactor (they'll need to be put in an interface somewhere, too - I wasn't sure what the best place for them would be): listenWith and connectWith. These take a type object that implements IListeningPort and IConnector respectively, and then perform similar operations to the other listen and connect methods, including serialization and rebinding the ports on application startup. Also added to Application is unlistenWith, an awkwardly named function that causes a listening Port to stop listening. Jp -- Lowery's Law: If it jams -- force it. If it breaks, it needed replacing anyway. -- up 38 days, 23:48, 5 users, load average: 1.88, 1.70, 1.66
On Thu, 23 Jan 2003 14:19:03 -0500
Jp Calderone
Attached patch adds two methods to Application and two methods to the default reactor (they'll need to be put in an interface somewhere, too - I wasn't sure what the best place for them would be): listenWith and connectWith.
I think the reactor implementations of the method should pass the reactor as the first arg to the connectorType or listenType, e.g.: + def connectWith(self, connectorType, *args, **kw): + c = connectorType(self, *args, **kw) + c.connect() + return c
A few comments made by other people on IRC that I want to make sure are archived somewhere, because maybe they things I've seen while trying to clean up freshcvs persistability recently. The context is a discussion of exarkun's upcoming patch, based on the one in the start of this thread. <glyph> exarkun: listenWith ought to say something about the persistability of the IListeningPort being passed in. <exarkun> glyph: it's taking a class/type - those should always be persistable, yea? <glyph> exarkun: Not necessarily; sockets aren't persistable, so it's easy to screw up a ListeningPort instance :-) <exarkun> Ahh, hmm <glyph> oh wait, hang on, you're right ... <glyph> This illustrates a serious flaw in the design of Application :-\ <glyph> or well, not serious, but annoying. <glyph> Really we ought not be storing constructor arguments, we should be storing state objects. * exarkun nods, "That would be better." <glyph> That's the way it started out, but when the reactor refactor happened this didn't get cleaned up like it should have. (Some settling may have occurred during transcription.) -- The moon is waning crescent, 6.0% illuminated, 27.2 days old.
maybe they [relate to] things I've seen while trying to clean up freshcvs persistability recently.
namely, http://twistedmatrix.com/pipermail/twisted-commits/2003-January/005689.html
participants (3)
-
Itamar Shtull-Trauring -
Jp Calderone -
Kevin Turner