True, it's not as simple as checking for the existence of an attribute, but it could throw an exception. It seems like having both asBlob and asArrayBuffer also creates the possibility of bad combinations of settings which could get confusing, especially if more types are added in the future.
Chris On Mon, Oct 25, 2010 at 3:04 PM, Darin Fisher <[email protected]> wrote: > How do you address the discoverability issue that I raised? asBlob and > asArrayBuffer have the benefit of being detectable at runtime. but, a > settable responseType does not support detection of supported values. > > -Darin > > > > On Mon, Oct 25, 2010 at 2:54 PM, Chris Rogers <[email protected]> wrote: > >> passing "undefined" as the 4th and 5th arguments seems pretty clunky to >> me. Since, we already have an "asBlob" attribute, then "asArrayBuffer" like >> Darin suggests seems like it might be better. However, then we can get into >> cases where both "asBlob" and "asArrayBuffer" are set, and this problem >> would get even worse as new types are added. So, an attribute called >> "responseType" might be a good solution. This would be instead of passing >> it as an argument to open(), and instead of having an "asBlob" attribute. >> This approach seems the cleanest to me, and I'll propose it to the >> appropriate standards group. >> >> Chris >> >> On Mon, Oct 25, 2010 at 12:45 PM, Alexey Proskuryakov <[email protected]>wrote: >> >>> >>> 25.10.2010, в 12:34, Chris Marrin написал(а): >>> >>> 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: >>> >>> >>> Note that open() has username and password as its 4th and 5th arguments. >>> So, you'd have to call it like request.open("GET", "data.xml", true, >>> undefined, undefined, "Bytes"); >>> >>> - WBR, Alexey Proskuryakov >>> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> [email protected] >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >>> >> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
