- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 9 Nov 2010 12:03:22 -0800
- To: Chris Rogers <crogers@google.com>
- 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>, Anne van Kesteren <annevk@opera.com>, Eric Uhrhane <ericu@google.com>, michaeln@google.com, Alexey Proskuryakov <ap@webkit.org>, jorlow@google.com, jamesr@chromium.org
On Tue, Nov 9, 2010 at 11:54 AM, Chris Rogers <crogers@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 still don't see the problem with the responseType. There's very little difference in both BinaryHttpRequest and responseType is opt-in mechanisms. 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. / Jonas
Received on Tuesday, 9 November 2010 20:04:18 UTC