On Mon, Oct 25, 2010 at 12:34 PM, Chris Marrin <cmar...@apple.com> wrote:
>
> 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 <gga...@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.
>
>
Why is that superior to more specifically named attributes and methods? I'm
trying to see how you would determine at runtime if a browser's XHR
implementation supported returning an ArrayBuffer.
If the XHR had an .asArrayBuffer attribute, then you could test for the
existence of that attribute.
I'm also not sure why adding new response types is cheaper than adding new
attributes / methods. In both cases, it seems like we have to have a
similar "standards" discussion.
-Darin
> -----
> ~Chris
> cmar...@apple.com
>
>
>
>
>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
