[Twisted-Python] Re: async code structure question

[snacktime]

On Thu, 10 Feb 2005 14:41:32 -0800 (PST), David Bolen <db3l at fitlinxx.com> wrote:
> 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.

I thought about this approach, but I kind of like the idea of having
the deferred that fires off PrintData at the very top and pass the
deferred around in the request object for the request.  That way I can
trigger a message back to the client from anywhere.

Chris