I skimmed the thread before starting this and saw that you were pointing out some issues but didn't think you're opposing so much.
---- Let me check requirements. a) We don't want to introduce a completely new object for streaming HTTP read/write, but we'll realize it by adding some extension to XHR. b) The point to connect the I/O API and XHR should be only the send() method argument and xhr.response attribute if possible. c) The semantics (attribute X is valid when state is ..., etc.) should be kept same as other modes. d) The I/O API needs to work with synchronous XHR. e) Resource for already processed data should be able to be released explicitly as the user instructs. f) Reading with maxSize argument (don't read too much). g) The I/O API should allow for skipping unnecessary data without creating a new object for that. Not requirement h) Some people wanted Stream to behave like not an object to store the data but kinda dam put between response attribute and XHR's internal buffer (and network stack) expecting that XHR doesn't consume data from the network until read operation is invoked on Stream object. (i.e. Stream controls data flow in addition to callback invocation timing). But it's no longer considered to be a requirement. i) Reading with size argument (invoke callback only when data of the specified amount is ready. Only data of the specified size at the head of stream is passed to the handler) On Fri, May 17, 2013 at 2:41 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > On Thu, May 16, 2013 at 6:31 PM, Travis Leithead > <travis.leith...@microsoft.com> wrote: > > Since we have Streams implemented to some degree, I'd love to hear > suggestions to improve it relative to IO. Anne can you summarize the points > you've made on the other various threads? > > I recommend reading through > > http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg569 > > Problems: > > * Too much complexity for being an Blob without synchronous size. > * The API is bad. The API for File is bad too, but we cannot change > it, this however is new. > > And I think we really want an IO API that's not about incremental, but > can actively discard incoming data once it's processed. > > > -- > http://annevankesteren.nl/ >
