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 <micha...@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 <ann...@opera.com> > wrote: > > On Tue, 09 Nov 2010 21:03:22 +0100, Jonas Sicking <jo...@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/ > > >