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/
> >
>