W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

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

From: Chris Rogers <crogers@google.com>
Date: Wed, 10 Nov 2010 13:26:57 -0800
Message-ID: <AANLkTinyQ8g_8Eb8wrmpWFHTicx7XbjtyeeLFgrBy85a@mail.gmail.com>
To: Michael Nordman <michaeln@google.com>
Cc: Anne van Kesteren <annevk@opera.com>, Jonas Sicking <jonas@sicking.cc>, David Flanagan <david@davidflanagan.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org, Maciej Stachowiak <mjs@apple.com>, Geoffrey Garen <ggaren@apple.com>, Darin Fisher <darin@chromium.org>, Eric Uhrhane <ericu@google.com>, Alexey Proskuryakov <ap@webkit.org>, jorlow@google.com, jamesr@chromium.org
I don't have a strong preference either way (adding responseType to XHR, or
creating a new BinaryHttpRequest).
If we do choose the responseType approach, should its value be an enum, or a
string?

Chris

On Wed, Nov 10, 2010 at 12:44 PM, Michael Nordman <michaeln@google.com>wrote:

> 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 21:27:31 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:41 GMT