Re: Streams and Blobs

On Tue, Feb 26, 2013 at 10:38 AM, Anne van Kesteren <annevk@annevk.nl>wrote:

> > We can get "chunked" reads without an additional mode.  Just add an
>
> additional method, eg. clearResponse, which empties .response.  This would
> > work for all modes that support incremental reads.  For Blobs, this would
> > cause .response to return an empty blob and start filling up from
> scratch.
> > In other words, .response in incremental blob mode returns a slice of the
> > complete response in the range [start,end), where end is the total
> number of
> > bytes read, start is initialized to 0, and clearResponse sets start =
> end.
>
> Keeping the API closer to responseType/response seems nicer.
>

I disagree.  That means creating a big matrix of responseTypes for ("blob",
"arraybuffer", "text") * ("chunked", "incremental"), to control what are
really two separate behavioral switches.

This is also easier to use.  If you want to process data 100 KB at a time,
you simply do:

var check_for_data = function()
{
    // Return if we have too little data and more data is coming.
    if(xhr.response.size < 102400 && xhr.readyState != xhr.DONE)
        return;
    var blob = xhr.response;
    xhr.clearResponse();

    // do work
}

xhr.onprogress = function(e) { check_for_data(); }

With an API that uses a separate responseType and clears the blob chunk
automatically, you'd have to accumulate the data yourself.  Also, you'd
have to worry about double-processing data (knowing precisely when the
.response chunk is replaced to make sure you don't process the same chunk
twice).

(In principle, there are three modes: "all at once", which we have today,
"incremental" and "chunked".  We could probably avoid adding any new
responseTypes at all.  If it's web-compatible, just change .response to
return incremental data.  If it isn't, add an .incrementalResponse
property.  This keeps the type of response--blob, text,
ArrayBuffer--orthogonal from whether data is exposed incrementally or not.)

-- 
Glenn Maynard

Received on Tuesday, 26 February 2013 17:32:00 UTC