Mary Gardiner
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