W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

From: Chris Marrin <cmarrin@apple.com>
Date: Tue, 26 Oct 2010 16:55:19 -0700
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
Message-id: <03F46514-9E6D-4FB9-8733-9BC51D6A1B6E@apple.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>

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
cmarrin@apple.com
Received on Tuesday, 26 October 2010 23:55:59 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:41 GMT