[Twisted-web] twisted.web2.stream.IStream.reset()?

[Scott Lamb]

On 23 Sep 2005, at 14:37, Jp Calderone wrote:

> Many stream sources cannot be rewound.  Implementing reset for  
> IStream would require many implementations to hold their entire  
> contents in memory.  This is completely unreasonable.  Creating a  
> separate interface for streams which could be rewound would avoid  
> this problem, but at the same time limit the actual implementations  
> your code could work with to an extreme subset.
>
> Instead of extending IStream or creating a new interface, you  
> probably want to wrap request.stream before passing it to the  
> request.  The wrapper can take care of providing restartability.   
> It can also prevent the concurrency bugs that handing a single  
> stream to multiple Requests will present.

On second, thought, i don't buy this at all. You're saying that this  
wrapper should provide the buffering itself to provide  
restartability? Will the data be large / should this buffering happen  
in memory or on disk? For MemoryStream and FileStream, the answers  
differ. In both cases, the buffering is silly, though; they have all  
the information to reset themselves.

CompoundStream, TruncaterStream, and PostTruncaterStream could all be  
made resettable, provided the streams that they operate on are.

Only ProducerStream differs. I don't think it's unreasonable to say  
that caller should wrap it before feeding it to web2.client.Request.  
Only the caller knows whether in-memory or on-disk buffering makes  
more sense. Maybe neither - if it could be produced once, maybe the  
best thing is to produce it again.

ProducerStream is already different in that it doesn't  
support .length. What's another optional operation?

-- 
Scott Lamb <http://www.slamb.org/>