Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

On Fri, Oct 29, 2010 at 10:43 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/28/10 11:29 PM, Jonas Sicking wrote:
>>
>> Personally I like the proposed responseType solution.
>
> The one where you pick one up front and it throws if you ask for something
> else, right?
>
>> I agree that it has a downside in that it doesn't allow figuring out
>> the type as data starts coming in.
>
> Well, that, and the whole "throws exceptions" bit...

I'm not entirely following what your concern is. I.e. what usage
pattern you are worried will either break in existing code, or people
will get wrong in new code.

My suggestion is that we add a .response property which always contain
the result, no matter what type is being fetched. In the "default"
mode, when .resonseType is not set, it can contain the same value as
.responseText currently contains. If .responseType is set to "blob" it
will return a Blob object, if it's set to "binary" it will return a
ArrayBuffer etc.

Yes, it will mean that if people do xhr.response.slice(x,y), it will
throw if they had set .responseType to something other than "blob".

>> I also am not a big fan of the
>> lazy-decode-into-whatever-format-users-want. It makes it much too easy
>> for a site to use up more memory and CPU than it needs.
>
> As opposed to having sites decode themselves?  I'm not sure there's much
> difference.

Like maciej showed, if we expose multiple properties which at the same
time contain the result data in different formats, it's very easy to
accidentally use more memory than needed. For example by checking
progress by measuring .responseText.length, or by checking what type
was returned by poking at the various properties until finding one
that works.

>> For users that can handle
>> progressive handling of the downloaded content, keeping all the
>> so-far-downloaded data in memory is pure waste.
>
> Sure.  The question is how to make their lives better without making others'
> lives worse (or at least too much worse?).

I say by making it possible to choose if you want streaming or
give-me-the-full-result-once-all-of-it-is-downloaded behavior. If need
be before the request is started.

>> (To make matters worse, we don't just keep all the data in memory, but for
>> each
>> additional downloaded piece of content, we over and over reallocate a
>> ever-expanding block of memory.
>
> That seems like an implementation detail.  Nothing is really preventing
> segmented storage of the data (not even the responseArrayBuffer getter, if
> it were added).

Indeed, though at some point the implementation likely will have to
flatten the data in order to not have to support fragmented
strings/arraybuffers throughout the JS engine.

>> For the case when it's known what type of response is expected this
>> seems to work very well.
>
> As long as only one entity is doing the expecting, right?  Right now jquery
> expects to get responseText, so if you expect something else you can't use
> jquery's XHR wrappers, say....

I'm not terribly worried about library wrappers. My money is on
libraries updating faster than browsers are releasing implementations.

>> For the case when looking at the response body is required to
>> determine how the response should be handled I'm less sure. One
>> solution would be to say that people can just use .responseType =
>> "binary" or .responseType = "blob" and then do the processing
>> themselves.
>
> This actually seems ok to me if we have APIs for doing that.  Seems like an
> excellent idea, in fact.
>
> Again, my concern is that the exception-throwing behavior is error-prone,
> and worse yet that we have existing uses of the API that make certain
> assumptions that the behavior will break.  If this were a brand-new API I
> could perhaps be convinced to do the exception thing, since that's just how
> it would be.  I'm really worried about deploying that sort of thing into the
> existing environment, though.

I've assumed that all proposals made so far maintain full backwards
compatibility. So I'm not terribly worried about existing content. Old
browsers will hold people back much more than old JS libraries.

/ Jonas

Received on Saturday, 30 October 2010 07:35:53 UTC