- From: Anne van Kesteren <annevk@opera.com>
- Date: Wed, 10 Nov 2010 11:42:25 +0100
- To: "Chris Rogers" <crogers@google.com>, "Jonas Sicking" <jonas@sicking.cc>
- 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>, michaeln@google.com, "Alexey Proskuryakov" <ap@webkit.org>, jorlow@google.com, jamesr@chromium.org
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 10:43:16 UTC