[Twisted-web] Is there a way to implement a deferred sequence?

Alexey S. twisted-web at udmvt.ru
Fri Apr 10 05:41:28 EDT 2009


On Fri, Apr 10, 2009 at 08:43:39AM -0000, glyph at divmod.com wrote:
>
> Because Deferreds are intended to be an asynchronous mechanism for  
> control flow.  They are the way to return a value which is not yet  
> present.  In other words they are an asynchronous version of exit  
> semantics; "return" and "raise".
>
> They are very explicitly *not* designed to simultaneously implement  
> asynchronous versions of every other potential control flow - looping,  
> for example, which seems to be what you want.

Yes, but there is no synchronous version of what I want, I can't name any.
Asynchronousness adds some more capabilities to be introduced into flow control.
>From my perception Deferred is a point where two entities exchange events
(one send, other receive)
And if we think about Deferred as an event router, then my question was
"why there is only two types of events possible and both of them are 'final' events?"
I just asked about subclassing that event router to include capability
to route some other events in addition to two existing.
It is worth noting, that such improvement does not forbid Deferred from being
"the way to return a value which is not yet present". It just make the term
"value" more complex, allows it to be dispersed in time, not only concentrated
at a single moment. I think there is no natural analogy for synchronous flow
control and can't be - results are not synchronous.
Perhaps the thing I am talking about should not be called "Deferred", since
it is only asynchronous version of syncronous flow control. But for me
extending Deferred looks natural, that is why I am asking.

>
> There are other mechanisms for doing those things.  For example, if you  
> want to get a stream of data and handle it incrementally, you want to  
> implement an IProtocol or ITransport.  Trying to cram all of IProtocol  
> into Deferred is a mistake.
IProtocol and ITransport looks like being a byte-oriented interfaces, not
an arbitrary-object-oriented.

>
> If you want some abstraction to support an incremental stream of results  
> with a size known in advance, for example to support drawing a progress  
              ^^^^^ - did you mean unknown?
> bar on an upload or download, then please feel free to propose that as a  
> *separate* mechanism from Deferred, and we can debate its merits and  
> usefulness on its own.  But I doubt very much that Deferred should do  
> such a thing itself.
I am asking for an half-duplex Event-pipe which can be closed from the sending end.
Just as variant it can be used to deliver cumulative results, but not fixed to that.
I said "Deferred" because the implementation of such thing will be identical to
Deferred's. It will be a Deferred with additional callback(s) which is(are) not
restricted to be invoked only once. 

Thank for your time.

-- 
Alexey S.



More information about the Twisted-web mailing list