<div dir="ltr">Hi Nick<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 22, 2013 at 10:40 AM, Nick Johnson <span dir="ltr"><<a href="mailto:Nick.Johnson@ed.ac.uk" target="_blank">Nick.Johnson@ed.ac.uk</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Firstly, thanks for this gist, I had done a few experiments using<br>
endpoints and I think this is definitely the way to go for this code.<br></blockquote><div><br>Welcome :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


As to the questions: source and destination are parameters for the job<br>
and might change between runs (a function I didn't include for brevity<br>
handles computation of these). Interval was to be the time passed to<br>
LoopingCall and type_req was another job parameter.<br>
<br>
I agree that, having looked at the gist, trying to pack everything into<br>
one Protocol was not the best way to go and using a separate protocol<br>
for each type of communication (ie, getjob, retrievejob) is more sensible.<br></blockquote><div><br></div><div>For what it's worth: a protocol implementing all of these might make even more sense if you have some functions as the high level API (like the ones I wrote in the gist): the functions could call high level methods on the protocol that cause it to do certain things.<br>

<br></div><div>As an example, consider the IRCClient protocol: <a href="https://twistedmatrix.com/documents/current/api/twisted.words.protocols.irc.IRCClient.html">https://twistedmatrix.com/documents/current/api/twisted.words.protocols.irc.IRCClient.html</a><br>

<br></div><div>... which has methods like "join", "leave", "say", "message"...<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


Thanks for helping me out with this, Twisted is slowly starting to make<br>
sense now.<br>
<br>
Cheers,<br>
-Nick.<br>
<div class=""><div class="h5"><br>
<br>
On 19/07/13 14:52, Laurens Van Houtven wrote:<br>
> Hi Nick,<br>
><br>
><br>
> Okay, question and code review time. Why are source and destination<br>
> arguments to the protocol? Can't they just access it on the factory?<br>
><br>
> It seems that the factory initiates many connections with the same<br>
> parameters. Is that true? Does it only ever make sense to use the<br>
> factory to fire many requests?<br>
><br>
> Anyway, the biggest issue seems to be that you're stuck on trying to do<br>
> everything with one protocol; it might make total sense for you to have<br>
> a job-queueing and a job-getting protocol :)<br>
><br>
> Can you explain what the interval and type_req arguments are, and why<br>
> they're passed to the factory?<br>
><br>
> cheers<br>
> lvh<br>
><br>
<br>
</div></div><div class=""><div class="h5">--<br>
The University of Edinburgh is a charitable body, registered in<br>
Scotland, with registration number SC005336.<br>
<br>
</div></div></blockquote></div><br></div></div>