[Twisted-Python] Re: async code structure question

[David Bolen]

Mary Gardiner <mary-twisted at puzzling.org> writes:

> Somehow authorize needs to have the deferred accessible. There's no
> magical Deferred way of doing this, you do it the way that you'd make
> any other piece of data accessible to a method: pass it to the method,
> or having it accessible as self.d would be the standard ways.

Alternatively, the authorization class/code can just make its own
deferred (either directly or by performing a deferred operation) and
returns it to its caller.  The caller of authorize then sees it as a
deferable operation (returning a deferred) onto which it can hang any
callbacks, which which might be as simple as chaining to the initial
deferred.

If there's an intermediate layer (such as the ProcessTransaction class
in the example), it can just return the authorize deferred as its own
result without doing anything to it (unless it does in fact want to do
some post processing to authorizes result) up the chain.

snacktime, in your sample, this could avoid your use of callLater in
OT, since you could just call c.Do(data) and use the deferred that it
returned to hang your self.PrintData callback on.  Within your
ProcessTransaction and Vital classes, your "response" object would be
the deferred being passed up from the authentication layer, possibly
after some callback processing (although your example code didn't show
those objects manipulating response in any way).

If you think about this from the bottom up, your authentication
operations become the ones which are promising an eventual answer (and
on which all the rest of the processing rests) by returning a
deferred, either by generating one locally or already being layered on
a deferrable operation, via the network, a deferToThread blocking
call, a adbapi call, etc...

In turn, the other layers that sit above that deferrable operation
simply make use of that low level Deferred object on which they hang
whatever processing they need.

-- David