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 <[email protected]> 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
[email protected]
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
