W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Streams and Blobs

From: Wenbo Zhu <wenboz@google.com>
Date: Wed, 6 Mar 2013 23:02:51 -0800
Message-ID: <CAD3-0rMS3kKJMrvhpkgUJMn_Xc0zMMsSUJ2fcCR0+pbR-1W1nQ@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>
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.

I've asked the similar question before  (streamed send and
... Also, HTTP chunked transfer-encoding is not really relevant here,
although implementations may have used T-E chunks as delivery units.

> --
> Glenn Maynard
Received on Thursday, 7 March 2013 07:03:19 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:52 UTC