Re: Streams and Blobs

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

> The advantage the Streams API seems to have over moz-blob is that you

do not need to create a new object to read from each time there's
> fresh data. The disadvantage is that that's only a minor advantage and
> there's a whole lot of new API that comes with it.
>

I suppose a use case would be making a POST request or a request with
special headers set to access a video stream.  You can createObjectURL on
the resulting Stream and pass that to <video>.

Did I miss something?
>
> I'm kinda leaning towards adding incremental Blob and chunked
> ArrayBuffer support and removing the Streams API. I can see use for
> Stream construction going forward to generate a request entity body
> that increases over time, but nobody is there yet.
>
> (Also, in retrospect, I think we should have made Blob's be able to
> increase in size over time and not have the synchronous size
> getter...)
>

Yeah, the sync size getter is unfortunate.  I've wondered about taking Blob
and splitting out a base class without the size getter, but it's probably
not worth it now.  (Actually, wait.  That's almost exactly what Stream is.
 Hmm.)

I don't think it's a problem that Blob's size is immutable.  It's fine to
have XHR create and return a new Blob object each time you read .response,
since they'd all share the same underlying storage.

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.

-- 
Glenn Maynard