- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 25 Oct 2010 19:51:26 -0400
- To: Chris Marrin <cmarrin@apple.com>
- CC: Chris Rogers <crogers@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Anne van Kesteren <annevk@opera.com>, Eric Uhrhane <ericu@google.com>, michaeln@google.com, Darin Fisher <darin@google.com>, Alexey Proskuryakov <ap@webkit.org>, Geoffrey Garen <ggaren@apple.com>, jorlow@google.com
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? > 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.... > 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... -Boris
Received on Monday, 25 October 2010 23:52:02 UTC