James Y Knight
foom at fuhm.net
Mon Sep 26 13:04:09 MDT 2005
On Sep 24, 2005, at 12:41 PM, Scott Lamb wrote:
> 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.
Doing any sort of automatic buffering is going to be a bad solution,
because you won't be able to discard the buffer until you've got the
final response from the other side, which may not happen until you've
sent all 20GB of data, two days from now. If the server is well-
designed, it will send an authorization denied error before you've
uploaded everything, but you cannot rely on that. And you really
don't really want to have the server buffer all that data for two
days. Of course, you also don't want to upload it twice, but some
things you've just gotta live with. So, anyhow, I think any buffering
must be explicit so the developer has to explicitly ask to shoot
themselves in the foot.
Also, I've tried to keep the stream API and implementation relatively
simple and easy to understand. Some bits of it do get complicated
already, but I think adding reset will complicate it quite a bit
further for any non-trivial stream. So, what do you do? Probably it'd
be best to pass something from which you can get a stream, rather
than a stream itself. Thus if you need to get the stream again, you
can call the function again. No muss, no fuss.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Twisted-web