Re: Lazy Blob

Can we please stop saying "lazy blob"?  It's a confused and confusing
phrase.  Blobs are "lazy" by design.

On Wed, Aug 1, 2012 at 2:26 PM, Glenn Adams <glenn@skynav.com> wrote:

> So? Why should lazy blob be specific to HTTP specific semantics when an
> arbitrary URL is not specific to HTTP?
>

XHR is no more specific to HTTP than it is to XML.  It serves as the
primary JavaScript API for performing generic network fetches.  WebSockets
has an entirely different API from blobs, and bringing them up is only
derailing the thread.

On Wed, Aug 1, 2012 at 2:32 PM, Michael Nordman <michaeln@google.com> wrote:

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

I like the idea of being able to retrieve a Blob for a URL via XHR, but I'm
uneasy about exposing the transfer-encoding (eg. whether Content-Length is
known in advance or not).  It's very confusing to move your code between
servers and to have things mysteriously break because the server uses a
different Transfer-Encoding.  I think web APIs should avoid exposing this
at all.

A middle-ground, if not an ideal one, would be for the Blob to return after
the HEAD request if Content-Length is present.  However, if it's absent,
perform the complete fetch before returning the Blob.  That would at least
abstract away the HTTP specifics, so code wouldn't break.

That said, this approach (with or without "greedy downloading for
chunked") may not quite fit some of the OP's use cases.  In particular, if
you have 1000 URLs and you want to hand Blobs off to another page in this
way, then while this wouldn't retrieve them all, it would still result in
1000 HEAD requests.

Sending XHR itself between contexts seems like it would be prickly from a
security standpoint.  A possible solution would be a higher-level wrapper,
eg. a thin abstraction of XHR that can only send a request and receive the
result (eg. exposing a very small subset of XMLHttpRequest's interface).
 That's much more heavyweight than the Blob approach, though, and I don't
have an opinion on whether the use cases justify it.

-- 
Glenn Maynard