slamb at slamb.org
Sat Sep 24 10:41:35 MDT 2005
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/>
More information about the Twisted-web