Re: Streams and Blobs

On Tue, Feb 26, 2013 at 7:53 AM, Glenn Maynard <glenn@zewt.org> wrote:

> 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.
>
+1

I've asked the similar question before  (streamed send and
receive<http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0104.html>)
... Also, HTTP chunked transfer-encoding is not really relevant here,
although implementations may have used T-E chunks as delivery units.


> --
> Glenn Maynard
>
>