[Twisted-Python] Best way to trigger a future connection with data

Nick Johnson Nick.Johnson at ed.ac.uk
Mon Jul 22 02:40:14 MDT 2013


Hi,

Firstly, thanks for this gist, I had done a few experiments using
endpoints and I think this is definitely the way to go for this code.

As to the questions: source and destination are parameters for the job
and might change between runs (a function I didn't include for brevity
handles computation of these). Interval was to be the time passed to
LoopingCall and type_req was another job parameter.

I agree that, having looked at the gist, trying to pack everything into
one Protocol was not the best way to go and using a separate protocol
for each type of communication (ie, getjob, retrievejob) is more sensible.

Thanks for helping me out with this, Twisted is slowly starting to make
sense now.

Cheers,
-Nick.


On 19/07/13 14:52, Laurens Van Houtven wrote:
> Hi Nick,
> 
> 
> Okay, question and code review time. Why are source and destination
> arguments to the protocol? Can't they just access it on the factory?
> 
> It seems that the factory initiates many connections with the same
> parameters. Is that true? Does it only ever make sense to use the
> factory to fire many requests?
> 
> Anyway, the biggest issue seems to be that you're stuck on trying to do
> everything with one protocol; it might make total sense for you to have
> a job-queueing and a job-getting protocol :)
> 
> Can you explain what the interval and type_req arguments are, and why
> they're passed to the factory?
> 
> cheers
> lvh
> 

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.




More information about the Twisted-Python mailing list