On Wed, Oct 27, 2010 at 12:12 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 10/27/10 2:39 AM, Darin Fisher wrote: > >> I think XMLHttpRequest is trying to be too much of a kitchen-sink. >> > > OK, something we agree on. ;) > > > Ideally, there'd be separate components that operate on an ArrayBuffer >> and produce a decoded string / XML document. Then, for the use case you >> are talking about, people could just ask for the response as an >> ArrayBuffer, inspect the response headers, and then optionally invoke a >> text decoder interface or a XML parser / DOM builder interface. >> > > My worry is about fragility we introduce in situations where the person > dispatching the XHR (library author or page author) and the person(s) > reading the results (library/page authors) are not the same set. As long as > the same object provides both views and the views are mutually exclusive, > it's really easy for the dispatcher to change what they ask for and subtly > break other consumers he doesn't even know about. > > I'd be much happier with either separate objects that provide different > views and can't be confused for each other or all the possible views being > available on demand. > > > As for the performance discussion, we learned the hard way that it was >> valuable to only keep one copy of the XHR's data. There are some sites >> out there that load large documents. Sad, but true. Maybe James >> Robinson or someone else can dig up some examples. >> > > Those would be helpful, yes. > > > I think we should try to design for a future where we don't have to >> compromise performance >> for capabilities. >> > > If we can do that without compromising capabilities for performance too > much, yes. Need to strike a balance. > > > If we keep the ArrayBuffer up front and only decode on demand, then we >> will be doing more work in the common case (in which someone only wants >> the responseText). That seems bad. >> > > Well, sure. The question is how much more work it is, and how bad the > other options are. > > -Boris > So, it sounds like we just need to present you with some concrete examples of XHRs being used to fetch large responses as Text or XML, and then you will be convinced? I wrote a web app that processes a subversion log using responseXML. Does that count? (The subversion log is pretty big. 45MB for all of WebKit.) -Darin