Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

Personally, I don't think new response modes is the proverbial straw
that breaks the camel's back.

I don't see the problem with selecting the responseType up front
either. It doesn't feel like a new class of object is warranted just
to provide the response body different forms. As Jonas pointed out,
any errors that occur when a new response mode is utilized (that makes
responseText unavailable to legacy library code) would be immediately
apparent to the developer attempting to use the new response mode and
easy enough to resolve.

Some arguments against new object types...

* If we do introduce a new object type that is nearly identical to the
existing object type,  that may introduce more compatibilities issues
than modest extensions to the existing object. Think script that is
designed to work with XHR being re-purposed for use with the new
nearly identical object, but not functioning properly because the new
object type is only "nearly" identical.

* Its that much more request handling bloatware in script to operate
with the different object types.

* Its that much more binding bloatware.




On Wed, Nov 10, 2010 at 2:42 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Tue, 09 Nov 2010 21:03:22 +0100, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> I still don't see the problem with the responseType. There's very
>> little difference in both BinaryHttpRequest and responseType is opt-in
>> mechanisms.
>
> I am not a big fan of a new object either. It would require two new objects,
> for one. It seems everyone keeps forgetting about the anonymous variant for
> convenience.
>
> During the meeting we discussed allowing responseType to be set just until
> after the headers were received so content negotiation could in theory still
> work. Presumably it would start throwing from the state LOADING onwards
> otherwise you get into trouble with disk-backed APIs (i.e. Blob) versus
> synchronous APIs (i.e. Document). This would not work with a new object that
> requires you to make a choice before things are being retrieved.
>
> It would be nice if we had something better than responseType though. It is
> very confusing given responseXML and responseText imo.
>
>
>> The only difference is that .responseType allows a existing object
>> (which a library could be holding a reference to) could be "mutated"
>> since it now behaves differently. It seems to me that whenever this is
>> done in the "wrong" way code should consistently fail, and so should
>> be easy for developers to deal with.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Received on Wednesday, 10 November 2010 20:45:22 UTC