<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">Hi again Tom</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">> So, it seems to me that you want to represent your jobs as</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">> more than simply a deferred. At the very least, you need to record what</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">> the jobs is, so that it can be restarted later, if necessary.</span><br style="font-family:arial,sans-serif;font-size:13px">
<br>Yes. The job class contained things like the function to call, its args, timing information etc., as well a deferred that would fire with the result.</div><div><br><span style="font-family:arial,sans-serif;font-size:13px">> Deferreds are a way of abstracting data and/or control flow in</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">> asynchronous way. I'm not sure that trying to think of a deferred as a</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">> job is a useful thing to do</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">I wasn't doing that.</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">The problem that I was originally trying to address by getting 'cancel' into deferreds is that the control flow you mention gets totally stuck if a deferred never fires for some reason (this was happening to me in talking to the Twitter API). E.g., in this case, kicking off a new job relies on an earlier job finishing (which includes a deferred firing).</span><span style="font-family:arial,sans-serif;font-size:13px"> An app writer might want to timeout a deferred for some reason. Or the app may need to shut down. If there's even one deferred that doesn't fire, the whole system essentially hangs. </span><span style="font-family:arial,sans-serif;font-size:13px">The idea was simply to increase the amount of control an app had over the flow of control.</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><font face="arial, sans-serif">This goes against the thinking that only the code that creates a deferred can fire it. I don't see anything wrong with that - it just increases the options that the code which obtains the deferred has. As API writers, we're used to being in control: we don't think it's a good idea if we create and return a deferred in a method and the code we return the deferred to then fires it itself. But as app writers consuming deferreds from these APIs, we want more control (I do, anyway).  It's possible to have both, which was what I was trying to provide for. The </font><span style="font-family:arial,sans-serif;font-size:13px">ControllableDeferred2013 class I posted last night shows one way. Adding a value arg to cancel() would build some of that flexibility into Twisted itself.</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Hopefully that helps makes things clearer.</span></div><div style>
<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Terry</span></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 21, 2013 at 7:18 AM, Tom Prince <span dir="ltr"><<a href="mailto:tom.prince@ualberta.net" target="_blank">tom.prince@ualberta.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Terry Jones <<a href="mailto:terry@jon.es">terry@jon.es</a>> writes:<br>
> But, I also built some queuing things where I would have liked extra<br>
> information. For example, an app is processing jobs on behalf of a user,<br>
</div>> [...]<br>
<br>
Thinking about this for a little bit, it seems like there is quite a bit<br>
more state to your jobs, that simply an eventual result (i.e. a<br>
deferred). So, it seems to me that you want to represent your jobs as<br>
more than simply a deferred. At the very least, you need to record what<br>
the jobs is, so that it can be restarted later, if necessary.<br>
<br>
Deferreds are a way of abstracting data and/or control flow in<br>
asynchronous way. I'm not sure that trying to think of a deferred as a<br>
job is a useful thing to do; most any example of a job that I can think<br>
of likely involves multiple deferred objects (often chained by returning<br>
them from callbcks).<br>
<span class="HOEnZb"><font color="#888888"><br>
  Tom<br>
</font></span></blockquote></div><br></div></div>