On Wed, Oct 27, 2010 at 12:34 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/27/10 3:23 PM, Michael Nordman wrote:
>
>> 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.
>>
>
> If we were designing from scratch, yes.
>
> Or is the proposal that we introduce the up-front modal switch and provide
> such APIs to allow consumers who want bytes-or-string to say they want bytes
> but then manually create the string later?
>
>
There wasn't a concrete proposal, just saying the division of labor between
data retrieval and data processing sounded good to me. I would be in favor
of concrete proposals in that direction and I view the responseArrayBuffer
attribute as a step in that direction.
> Note, by the way, that for XML and HTML types, one is required (per current
> XHR spec) to instantiate an XML or HTML parser, respectively, to produce the
> responseText (because the data can declare its own encoding in things like
> <meta> tags). I'm not sure whether that complicates the other interfaces
> being proposed.... I guess they could do that under the hood. But they
> point is they'd need to know the MIME type, not just the data.
>
So an XMLParser would need more than just the raw data, ok.
>
> -Boris
>