On Tue, Nov 9, 2010 at 12:03 PM, Tab Atkins Jr. <jackalm...@gmail.com> wrote: > On Tue, Nov 9, 2010 at 11:54 AM, Chris Rogers <crog...@google.com> wrote: >> Hi David, >> Sorry for the delayed response. I think the idea of BinaryHttpRequest is a >> reasonable one. As you point out, it simply side-steps any potential >> performance and compatibility issues. Are you imagining that the API is >> effectively the same as XMLHttpRequest, except without the text and XML >> part? >> How do other people feel about David's proposal? > > I'm in favor a new constructor. It seems silly to first hack > ourselves into a corner by extending an API designed for text or XML, > then try to hack our way out of the problems that causes. A new > object that does what's needed seems like the cleanest and most > correct solution to the problem.
After discussion with Anne and James, I retract my support for a new constructor. I'm in favor of .responseType. Specifically, .responseType would take values like "" (for legacy treatment) / "text" / "document" / "arraybuffer" / "blob" / etc. If the value is "", then .responseText and .responseXML are filled appropriately, while .response is empty. Otherwise, .responseText and .responseXML are empty (or throw or something), while .response contains the value in the chosen format. .responseType must be set at some appropriately early time; after the response is received, changes to .responseType are ignored or throw. ~TJ