[Twisted-Python] Returning a deferred from buildProtocol t.i.p.Factory

[exarkun at twistedmatrix.com]

On 05:44 pm, twisted at tomvn.com wrote:
>Thanks for both those suggestions.
>I'll be taking a closer look at txLoadbabancer when I get time as it 
>looks
>like it'll take care of a lot of my desired functionality out the box.
>To get started tho I'll move my async routing decision call into the
>protocol as suggested.
>
>Is there any reason why the internal calls to buildProtocol shouldn't 
>be
>wrapped in a maybeDeferred?

I'm not sure what you mean by "internal" here.  I think you might mean 
"calls to buildProtocol made by reactor implementations".  It is a 
mistake to take this perspective, though.  If buildProtocol is allowed 
to return a Deferred sometimes then *all* callers have to be prepared to 
handle a Deferred (by using `maybeDeferred` or using some other 
strategy).

This points to the reason *buildProtocol* can't be allowed to return a 
Deferred.  It is already defined as not returning a Deferred and 
changing this definition would potentially break every call, both those 
in reactor implementations and elsewhere (and there are plenty of other 
places that call `buildProtocol`).

Whether there is any good reason we could not introduce a new interface 
that is like `buildProtocol` but is also allowed to return a Deferred is 
another (more interesting :) question.  I can't think of any offhand.

The reactor would probably want to avoid monitoring new connections for 
read or write events until this Deferred fired (but bonus points if it 
still monitors it for connection lost and cancels the Deferred if this 
happens before it fires).  That's all relatively straightforward to 
implement though, for someone sufficiently motivated.

Jean-Paul