W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: Lazy Blob

From: Michael Nordman <michaeln@google.com>
Date: Wed, 1 Aug 2012 12:32:50 -0700
Message-ID: <CAHpoE=gzJ58iBdbP5HyauSP=NYcVFfwcCgREJbHk+TmEia4_Qw@mail.gmail.com>
To: Charles Pritchard <chuck@jumis.com>
Cc: Glenn Maynard <glenn@zewt.org>, Robin Berjon <robin@berjon.com>, WebApps WG <public-webapps@w3.org>, Jungkee Song <jungkee.song@samsung.com>
Maybe another XHR based way to phrase this: define a new response type for
XHR that results in the construction of a lazyBlob. I guess that's similar
to the more explicit xhr.makeLazyBlob() method, but allows its construction
to be async, and for greater reuse of the same signaling for progress and
errors, and to capture the results of a POST as a lazyBlob as well.

Knowing the length and to some degree the content-type upfront is trouble.
An xhr.responseType of 'stream' would have some trouble with the
content-type too.


On Wed, Aug 1, 2012 at 10:57 AM, Charles Pritchard <chuck@jumis.com> wrote:

> On Aug 1, 2012, at 8:44 AM, Glenn Maynard <glenn@zewt.org> wrote:
>
> On Wed, Aug 1, 2012 at 9:59 AM, Robin Berjon <robin@berjon.com> wrote:
>
>> var bb = new BlobBuilder()
>
> ,   blob = bb.getBlobFromURL("http://specifiction.com/kitten.png", "GET",
>> { Authorization: "Basic DEADBEEF" });
>>
>> Everything is the same as the previous version but the method and some
>> headers can be set by enumerating the Object. I *think* that those are all
>> that would ever be needed.
>>
>
> We already have an API to allow scripts to make network requests: XHR.
>  Please don't create a new API that will end up duplicating all of that.
>  However this might be done, it should hang off of XHR.
>
> Ideally, a new responseType could be added to XHR which operates like
> "blob", except instead of reading the whole resource, it just performs a
> HEAD to retrieve the response length and immediately returns the Blob,
> which can be read to perform further Content-Range reads.  This sits
> relatively cleanly within the XHR API.  It also has nice security
> properties, as if you send that Blob somewhere else--possibly to a
> different origin--it can do nothing with the Blob but read it as it was
> given.
>
> The trouble is chunked responses, where the length of the resource isn't
> known in advance, since Blobs have a static length and aren't designed for
> streaming.
>
>
>
> The "HEAD" request seems a little like a FileEntry for use with FileReader.
>
> Something similar (very similar) is done for http+fuse on several
> platforms.
>
> It's quite useful for working with large archives such as PDF or ZIP.
>
>
> -Charles
>
Received on Wednesday, 1 August 2012 19:33:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT