[html5] XHR Questions

[Gomer Thomas]

              Dear Anne,
              Thank you for clarifying what happened. 
              I don't understand the statement that "Yes, I took that out because of the reason I stated. It would require allocation of a great many objects and that was not seen as desirable." It would require the allocation of a buffer to handle the response to each HTTP request, which is always needed when an HTTP request is made. That buffer can be deleted as soon as the response is processed. The only difference between allowing and not allowing access to a partially filled buffer is that it takes longer before the buffer can be deleted at the end, because processing of the response cannot begin until the response is complete.
       I can understand the value of providing a more efficient new mechanism that will allow treating the response to an HTTP request as a stream, so that the entire response does not need to be buffered, but I don't understand why the (less efficient) existing mechanism must be removed years before the new mechanism is fully specified and widely implemented. That's not the way evolution usually works. Usually a better way of doing things gradually replaces the old way as it proves to be superior. (The XMLHttpRequest() spec dropped the incremental processing sometime between August 2009 and August 2011, and as far as I can tell the work on Streams started in October 2013. In the meantime, in November of 2011 the ISO DASH standard was approved, an application that could benefit from the incremental processing.) 
       I also don't understand the statement that " Note that responseText is not efficient either, but we could not remove that because it was already implemented." The only real difference between responseText and responseBody is the name. In both cases it is a buffer with bytes in it. If one is implemented, it is trivial to implement the other as well. Did browsers really implement the one and not the other? 
              Nonetheless, what is done is done, I guess. 
              Unfortunately, this whole exchange has left me uneasy about the WHATWG decision processes. Rather than just enabling a better way of doing things, the model seems to be to disallow the old way of doing things first, with the promise that a better way will emerge in the future. 
              
              Regards, Gomer Thomas
              --
              Gomer Thomas Consulting, LLC
              9810 132nd St NE
              Arlington, WA 98223
              Cell: 425-309-9933
              
              
              -----Original Message-----
       From: Anne van Kesteren [mailto:annevk at annevk.nl] 
       Sent: Saturday, March 19, 2016 10:58 PM
       To: Gomer Thomas <gomer at gomert-consulting.com>
       Cc: Domenic Denicola <d at domenic.me>; help at lists.whatwg.org
       Subject: Re: [html5] XHR Questions
              
              On Sat, Mar 19, 2016 at 7:29 AM, Gomer Thomas <gomer at gomert-consulting.com> wrote:
              >        For some reason, which I still don't understand, this capability was taken out by the time of the August 2011 version. In that version incremental consumption was only enabled for "text" type responses, not for "document" or "any" type responses.
              
              Yes, I took that out because of the reason I stated. It would require allocation of a great many objects and that was not seen as desirable.
              To do this efficiently you need streams. Note that responseText is not efficient either, but we could not remove that because it was already implemented.
              
              
              >        Since no one seems to know why the XMLHttpRequest() specification was changed to take away the incremental consumption capability for binary files, it seems unlikely it will be changed back any time soon, if at all (even though the current situation is a violation of the spirit of the specifications regarding support for chunked encoding in RFC 7230).
              
              It's not. XMLHttpRequest is just an API, it doesn't have to support all features of HTTP.
              
              
              >  Therefore, it appears that a proprietary solution based on a WebSocket will need to be implemented for the next couple of years at least, until Streams are mature and well supported.
              
              You'll need that either way, even if we changed XMLHttpRequest today, which we won't, it wouldn't be supported for quite a while.
              
              
              >        In fact, even then a proprietary solution to get Streams from a remote server to an application's browser context might be required. The Streams specification appears to assume that everything is happening locally. I guess one could put a local "Streams" wrapper around the WebSocket interface, but the advantages of that over a pure proprietary solution are not clear.
              
              Streams is being integrated with the fetch() API, which is the now favored way to do networking in a browser.
              
              Hope this clears things up a bit.
              
              
              --
              https://annevankesteren.nl/