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

Hi Boris.

> As long as the same object provides both views and the views are mutually exclusive, it's really easy for the dispatcher to change what they ask for and subtly break other consumers he doesn't even know about.

To the contrary, I think eliminating subtlety is the main benefit of explicitly selecting a response type and throwing exception on incorrect access.

Quietly providing multiple copies of data creates a subtle memory use problem.

Explicitly throwing an exception at the site that tries to access the data in the wrong way obviously and immediately points a finger at the problem.

The potential downside to an exception is not subtlety -- it's limited functionality: clients are no longer allowed to ask XHR to be more than one kind of data at once. The question is, can library authors make their code compatible with this limitation?

I don't think it's possible to answer that question until someone fleshes out your assumption that libraries routinely intercept XHRs in transit and read their data. Which libraries do this, when, and why?

> This make it impossible to decide whether to look at the text or the bytes based on the content-type of the response (unless you allow setting the attribute in some early-enough onStateChange callback _and_ libraries expose XHRs in that early a state to consumers); having that ability seems like a desirable feature.

I'm not convinced that clients loading resources from their own domains somehow won't know the types of those resources.

But, if we believe this is a real concern, it seems fine to me to allow responseType to be set some time after open, or even set implicitly by the first access to a certain view of the response. That way, clients wanting to delay the responseType decision can, while clients wanting maximum clarity and control can set responseType early.

Thanks,
Geoff

Received on Wednesday, 27 October 2010 18:57:08 UTC