On Oct 25, 2010, at 4:51 PM, Boris Zbarsky wrote: > On 10/25/10 7:05 PM, Chris Marrin wrote: >> I don't think we can say that. responseArrayBuffer is going to enable new >> uses of XHR. Floating point arrays for 3D mesh animation can easily get into >> the multi-megabyte range. > > Hmm... But will people still be accessing .responseText on those? And if > so, wouldn't they be broken by the proposals so far in this thread?
Probably not. But you'd either need to convert data from the raw form to the desired form on every call to responseXXX(), or store 2 copies of the data (the raw form and the most recently converted form). I believe the proposals are trying to get rid of the need for the performance or memory hit. > >> This replaces everything with 3 parts: >> >> any responseObject(); // Return an object based on the currently >> requested data type >> DOMString responseType(); Return the current type setting; >> >> The last part is adding a param to XHR.open() which specifies the desired >> type. > > This doesn't seem to allow deciding on the "type" based on the content type > returned by the server.... Is that a requirement? I don't understand XHR very well, but isn't there a way to get the header, determine the desired type and then do another get for the data? > >> We'd of course have to support the existing API for legacy. But the above >> API supplants the current responseText(), responseXML(), etc. > > I'm not sure I follow this part. So you'd have to support the new API _and_ > .responseText? I thought this was what you were trying to avoid... If this will be part of XMLHttpRequest then we need to support the legacy API. If this is part of a new XMLHttpRequest2 object or something, then we don't I guess. ----- ~Chris cmar...@apple.com
