You could aid discoverability -- and programming -- by providing a set of
enumerated constants on the XHR constructor, much like the Node constructor
provides for NodeTypes.
Another option would be to throw an exception when setting responseType to an
unsupported value.
Geoff
On Oct 25, 2010,
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.
Chri
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 wrote:
> passing "undefined
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
w
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 specifyin
On Mon, Oct 25, 2010 at 12:34 PM, Chris Marrin 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 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
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 wrote:
> Hi Chris.
>
> I like the efficiency of this approach. And I
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 pro
A few weeks ago I brought up the idea of implementing the
responseArrayBuffer attribute for XHR:
http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responsearraybuffer-attribute
One of the concerns was that it might require double the memory usage since
the raw bytes would have to be accumulated
10 matches
Mail list logo
