On Wed, Oct 27, 2010 at 12:34 PM, Boris Zbarsky <bzbar...@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 >
