
<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV>On Sep 24, 2005, at 12:41 PM, Scott Lamb wrote:</DIV><BLOCKQUOTE type="cite"><DIV>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.</DIV></BLOCKQUOTE></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>James</DIV><FONT class="Apple-style-span" color="#0000DE"></FONT></BODY></HTML>