- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 30 Oct 2010 01:43:33 -0400
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Maciej Stachowiak <mjs@apple.com>, Geoffrey Garen <ggaren@apple.com>, Darin Fisher <darin@chromium.org>, Chris Rogers <crogers@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Anne van Kesteren <annevk@opera.com>, Eric Uhrhane <ericu@google.com>, michaeln@google.com, Alexey Proskuryakov <ap@webkit.org>, Chris Marrin <cmarrin@apple.com>, jorlow@google.com, jamesr@chromium.org
On 10/28/10 11:29 PM, Jonas Sicking wrote: > Personally I like the proposed responseType solution. The one where you pick one up front and it throws if you ask for something else, right? > I agree that it has a downside in that it doesn't allow figuring out > the type as data starts coming in. Well, that, and the whole "throws exceptions" bit... > However I think this is a much less > common case then knowing the type before the request is made. I agree that far, yes. > I do think that supporting the case of downloading something which > type you don't know is a use-case that we need to support. But I don't > think that the way to do that is to have XHR parse things into every > conceivable format at the same time. I'm not suggesting it do that. > I also am not a big fan of the > lazy-decode-into-whatever-format-users-want. It makes it much too easy > for a site to use up more memory and CPU than it needs. As opposed to having sites decode themselves? I'm not sure there's much difference. > For users that can handle > progressive handling of the downloaded content, keeping all the > so-far-downloaded data in memory is pure waste. Sure. The question is how to make their lives better without making others' lives worse (or at least too much worse?). > (To make matters worse, we don't just keep all the data in memory, but for each > additional downloaded piece of content, we over and over reallocate a > ever-expanding block of memory. That seems like an implementation detail. Nothing is really preventing segmented storage of the data (not even the responseArrayBuffer getter, if it were added). > For the case when it's known what type of response is expected this > seems to work very well. As long as only one entity is doing the expecting, right? Right now jquery expects to get responseText, so if you expect something else you can't use jquery's XHR wrappers, say.... > For the case when looking at the response body is required to > determine how the response should be handled I'm less sure. One > solution would be to say that people can just use .responseType = > "binary" or .responseType = "blob" and then do the processing > themselves. This actually seems ok to me if we have APIs for doing that. Seems like an excellent idea, in fact. Again, my concern is that the exception-throwing behavior is error-prone, and worse yet that we have existing uses of the API that make certain assumptions that the behavior will break. If this were a brand-new API I could perhaps be convinced to do the exception thing, since that's just how it would be. I'm really worried about deploying that sort of thing into the existing environment, though. -Boris
Received on Saturday, 30 October 2010 05:44:11 UTC