[webkit-dev] XHR responseArrayBuffer attribute: possible implementation

[Chris Marrin]

On Oct 25, 2010, at 12:22 PM, Darin Fisher wrote:

> The solution for .responseBlob was to add an .asBlob attribute that would need to be set to true before calling .send().  We could do the same for .responseArrayBuffer.
> 
> -Darin
> 
> 
> On Mon, Oct 25, 2010 at 12:17 PM, Geoffrey Garen <ggaren at apple.com> wrote:
> Hi Chris.
> 
> I like the efficiency of this approach. And I agree with your premise that a developer will probably only want one type of data (raw, text, or XML) per request, and not more than one.
> 
> My biggest concern with this idea is that there's nothing obvious about the API pattern of three properties -- .responseText, .responseXML, and .responseArrayBuffer -- that makes clear that accessing one should prohibit access to the others. I wonder if there's a good way to make this clearer.
> 
> Maybe the API should require the programmer to specify in advance what type of data he/she will ask for. For example, an extra responeType parameter passed to open. The default behavior would be the values currently supported, but you could opt into something specific for extra safety/performance, and new types of data:
> 
> request.open("GET", "data.xml", true, "Text");
> request.open("GET", "data.xml", true, "XML");
> request.open("GET", "data.xml", true, "Bytes");

I'd sure like to try to avoid an explosion in the API. I like Geoff's suggestion of specifying the type of request in open(). Seems like the best API would be to have Geoff's API and then:

	any responseObject();
	DOMString responseType();

That would allow us to expand the types supported without any additional API. We'd need to support the current API calls for backward compatibility. But now seems like a good time to plan for the future.

-----
~Chris
cmarrin at apple.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101025/bd4b96d7/attachment.html>