Darin mentioned it earlier in this thread, having XHR return the raw data
and providing other interfaces to interpret/decode the raw data into
strings/xmlDocs. I like that decomposition.
> Because I'm skeptical that nested libraries trying to access the data both
ways will be an issue.
I'm not sure that is an issue either. To the extent it is an issue,
libraries could be updated to be sensitive to whether asArrayBuffer/asBlob
is set.
On Wed, Oct 27, 2010 at 11:56 AM, Geoffrey Garen <ggaren@apple.com> wrote:
> 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