- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 7 Mar 2013 19:40:19 -0800
- To: Glenn Maynard <glenn@zewt.org>
- Cc: Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>
On Thu, Mar 7, 2013 at 4:42 PM, Glenn Maynard <glenn@zewt.org> wrote: > The alternative argument is that XHR should represent the data source, > reading data from the network and pushing it to Stream. I think this is the approach I'd take. At least in Gecko this would allow the XHR code to generally do the same thing it does today with regards to actions taken on incoming network data. The only thing we'd do differently is which consumer to send the data to. We already have several such consumers which are used to implement the different .responseType modes, so adding another one fits right in with that model. >From an author point of view it also means that the XHR object behaves consistently for all .responseTypes. I.e. the same set of events are fired and the XHR object goes through the same set of states. The only difference is in how the data is consumed. The XHR object and the stream would still be separate objects. So aborting the XHR object would not affect the behavior of the Stream object, other than that it would stop further data from becoming readable through the stream. Possibly the stream would also indicate some sort of "abort" error once the end was reached. / Jonas
Received on Friday, 8 March 2013 03:41:16 UTC