Re: [XHR] support for streaming data
On Thu, 18 Aug 2011, Jonas Sicking wrote: > On Thu, Aug 18, 2011 at 1:16 PM, Ian Hickson wrote: > > On Wed, 17 Aug 2011, Chris Rogers wrote: > >> > >> Also, it would be good to get Ian's opinion about this since he's > >> working on similar stuff with Web Sockets. > > > > Right now WebSockets only works with complete messages, there's no > > streaming support. I suspect that if we add streaming support to the > > protocol and the API, it'll be exposed as some sort of Stream object, > > which would then have a way to get the data out of it in chunked form, > > maybe a growing list of ArrayBuffers or something. I haven't looked at > > it in detail yet. > > > > There would probably be some relationship to MediaStream, too; roc may > > have an opinion on this topic, as he has spoken about it before. > > What we're talking about here isn't really "streaming" as much as > "chunked". The equivalent feature would be to be able to incrementally > get data as a large websocket message was delivered. > > The usecase would be something like supporting incremental rendering of > attachments, even when the attachment is sent as a single websocket > message. > > However I think it's a bit early to start talking about this feature for > websockets. The websocket API doesn't even have support for progress > events for individual messages. And even the basic API is still far from > widely deployed in browsers. > > It's also less important since you can always support the use case by > chunking up the attachment into several websocket messages, and > reassemble them manually in the client. This is more work, but should > work. Indeed. I've no current intention of addressing this in WebSockets. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [XHR] support for streaming data
On Thu, Aug 18, 2011 at 1:16 PM, Ian Hickson wrote: > On Wed, 17 Aug 2011, Chris Rogers wrote: >> >> Also, it would be good to get Ian's opinion about this since he's >> working on similar stuff with Web Sockets. > > Right now WebSockets only works with complete messages, there's no > streaming support. I suspect that if we add streaming support to the > protocol and the API, it'll be exposed as some sort of Stream object, > which would then have a way to get the data out of it in chunked form, > maybe a growing list of ArrayBuffers or something. I haven't looked at it > in detail yet. > > There would probably be some relationship to MediaStream, too; roc may > have an opinion on this topic, as he has spoken about it before. What we're talking about here isn't really "streaming" as much as "chunked". The equivalent feature would be to be able to incrementally get data as a large websocket message was delivered. The usecase would be something like supporting incremental rendering of attachments, even when the attachment is sent as a single websocket message. However I think it's a bit early to start talking about this feature for websockets. The websocket API doesn't even have support for progress events for individual messages. And even the basic API is still far from widely deployed in browsers. It's also less important since you can always support the use case by chunking up the attachment into several websocket messages, and reassemble them manually in the client. This is more work, but should work. / Jonas
Re: [XHR] support for streaming data
On Wed, 17 Aug 2011, Chris Rogers wrote: > > Also, it would be good to get Ian's opinion about this since he's > working on similar stuff with Web Sockets. Right now WebSockets only works with complete messages, there's no streaming support. I suspect that if we add streaming support to the protocol and the API, it'll be exposed as some sort of Stream object, which would then have a way to get the data out of it in chunked form, maybe a growing list of ArrayBuffers or something. I haven't looked at it in detail yet. There would probably be some relationship to MediaStream, too; roc may have an opinion on this topic, as he has spoken about it before. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [XHR] support for streaming data
On Wed, Aug 17, 2011 at 3:22 PM, Chris Rogers wrote: > > > On Mon, Aug 8, 2011 at 5:13 PM, Jonas Sicking wrote: >> >> Hi All, >> >> XHR Level 2 does wonders for making XMLHttpRequest better. However >> there is one problem that we have run into with "streaming" data. >> >> Using .responseType="text" you can read the contents of the data as >> soon as it comes in, i.e. you don't have to wait for the "load" event >> to read the data. However you can't do the same for .responseType = >> "arraybuffer". This is with good reason as arraybuffers are immutable >> in size and you can't really know how much data you'll receive up >> front. (You can make guesses based on the "content-length" header, but >> it's not always there, and isn't always reliable even when it's >> there). >> >> Another problem is that even if the webpage is able use >> .responseType="text" and consume the data in an incremental manner, >> the UA still ends up accumulating and holding large chunks of data in >> memory. >> >> So in other words, the use case is pages that are able to >> incrementally consume binary and textual data and wanting to do so >> without having to wait until the whole resource has been downloaded, >> and do so without requiring the UA to hold large amount of data in >> memory. >> >> To solve this I propose we add two new values to .responseType: >> "streaming-text" and "streaming-arraybuffer". >> >> When .responseType is set to "streaming-text" then during each >> "progress" event, .response would be set to the text that was received >> since the last "progress" event (and since the "loadstart" event for >> the first "progress" event). >> >> Same thing when .responseType is set to "streaming-arraybuffer". In >> this case .response is set to an ArrayBuffer containing the data >> received since the last "progress" event. >> >> There is one non-ideal thing with this solution. Once the last chunk >> of data has arrived, at least Firefox doesn't fire a "progress" event, >> but instead just a "load" event. This means that people will have to >> consume data both from the "progress" event and from the "load" event. >> >> Another solution would to make sure to always fire a "progress" event >> for the last data before firing the "load" event. I personally like >> this approach more. There *might* even be reasons to do that to ensure >> that pages create progress bars that reliably reach 100% etc. >> >> / Jonas > > Hi Jonas, > I like the idea of getting access to the incrementally "streamed" data. I > think there are definitely some interesting use cases for it. > Instead of adding a "streaming-" prefix for "streaming-text" and > "streaming-arraybuffer", another approach would be to add a new attribute > .responsePresentation (not a very good name) which could have values: > "concatenated" > "chunked" > (or something like that) > The default value for .responsePresentation would be "concatenated", but > could be changed to "chunked" for the streaming behavior. > I'm not necessarily in favor of this approach versus "streaming-text" and > "streaming-arraybuffer", but just thought I'd bring it up. Given how closely this is tied to .responseType, I think it's better to have a single property rather than two. That will additionally give us proper behavior as far as throwing if you try to change the mode after data has already starting coming in. .responseType is defined to throw if you try to set it after the readystatechange event for the HEADERS_RECEIVED state. That is exactly what we want for the streaming mode flag. > Also, it would be good to get Ian's opinion about this since he's working on > similar stuff with Web Sockets. Indeed! / Jonas
Re: [XHR] support for streaming data
On Mon, Aug 8, 2011 at 5:13 PM, Jonas Sicking wrote: > Hi All, > > XHR Level 2 does wonders for making XMLHttpRequest better. However > there is one problem that we have run into with "streaming" data. > > Using .responseType="text" you can read the contents of the data as > soon as it comes in, i.e. you don't have to wait for the "load" event > to read the data. However you can't do the same for .responseType = > "arraybuffer". This is with good reason as arraybuffers are immutable > in size and you can't really know how much data you'll receive up > front. (You can make guesses based on the "content-length" header, but > it's not always there, and isn't always reliable even when it's > there). > > Another problem is that even if the webpage is able use > .responseType="text" and consume the data in an incremental manner, > the UA still ends up accumulating and holding large chunks of data in > memory. > > So in other words, the use case is pages that are able to > incrementally consume binary and textual data and wanting to do so > without having to wait until the whole resource has been downloaded, > and do so without requiring the UA to hold large amount of data in > memory. > > To solve this I propose we add two new values to .responseType: > "streaming-text" and "streaming-arraybuffer". > > When .responseType is set to "streaming-text" then during each > "progress" event, .response would be set to the text that was received > since the last "progress" event (and since the "loadstart" event for > the first "progress" event). > > Same thing when .responseType is set to "streaming-arraybuffer". In > this case .response is set to an ArrayBuffer containing the data > received since the last "progress" event. > > There is one non-ideal thing with this solution. Once the last chunk > of data has arrived, at least Firefox doesn't fire a "progress" event, > but instead just a "load" event. This means that people will have to > consume data both from the "progress" event and from the "load" event. > > Another solution would to make sure to always fire a "progress" event > for the last data before firing the "load" event. I personally like > this approach more. There *might* even be reasons to do that to ensure > that pages create progress bars that reliably reach 100% etc. > > / Jonas > Hi Jonas, I like the idea of getting access to the incrementally "streamed" data. I think there are definitely some interesting use cases for it. Instead of adding a "streaming-" prefix for "streaming-text" and "streaming-arraybuffer", another approach would be to add a new attribute .responsePresentation (not a very good name) which could have values: "concatenated" "chunked" (or something like that) The default value for .responsePresentation would be "concatenated", but could be changed to "chunked" for the streaming behavior. I'm not necessarily in favor of this approach versus "streaming-text" and "streaming-arraybuffer", but just thought I'd bring it up. Also, it would be good to get Ian's opinion about this since he's working on similar stuff with Web Sockets. Regards, Chris
Re: [XHR] support for streaming data
On Fri, 12 Aug 2011 21:18:43 +0200, Charles Pritchard wrote: On 8/12/11 12:03 PM, Anne van Kesteren wrote: Before we add yet another set of features, when are we going to attempt to get interoperability on the current feature set? Some time after adding another set of features, I'd imagine. This has always been the way of XHR. Really? In my experience there has not been much of an attempt to converge so far. We've got a pretty strong case for chunked array buffer as a -single- feature. Between Mozilla and WebKit, I'd imagine one of the vendors will implement this year. We'll see. I wrote a test suite of sorts for features prior to XMLHttpRequest Level 2, but so far it has seen little feedback. Also nobody has contributed tests for the new features added to XMLHttpRequest Level 2. Where's your test set from prior? I'm booked this month, but I'd be happy to pick it up next month. http://dvcs.w3.org/hg/webapps/file/6631738fc83b/XMLHttpRequest/tests/submissions/Opera has my tests it seems. (Not sure why they were moved from their original location without someone telling me.) Feedback and/or new tests would be awesome, thanks! -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] support for streaming data
On 8/12/11 12:03 PM, Anne van Kesteren wrote: On Tue, 09 Aug 2011 02:13:20 +0200, Jonas Sicking wrote: XHR Level 2 does wonders for making XMLHttpRequest better. However there is one problem that we have run into with "streaming" data. Before we add yet another set of features, when are we going to attempt to get interoperability on the current feature set? Some time after adding another set of features, I'd imagine. This has always been the way of XHR. We've got a pretty strong case for chunked array buffer as a -single- feature. Between Mozilla and WebKit, I'd imagine one of the vendors will implement this year. I wrote a test suite of sorts for features prior to XMLHttpRequest Level 2, but so far it has seen little feedback. Also nobody has contributed tests for the new features added to XMLHttpRequest Level 2. Where's your test set from prior? I'm booked this month, but I'd be happy to pick it up next month. -Charles
Re: [XHR] support for streaming data
On Tue, 09 Aug 2011 02:13:20 +0200, Jonas Sicking wrote: XHR Level 2 does wonders for making XMLHttpRequest better. However there is one problem that we have run into with "streaming" data. Before we add yet another set of features, when are we going to attempt to get interoperability on the current feature set? I wrote a test suite of sorts for features prior to XMLHttpRequest Level 2, but so far it has seen little feedback. Also nobody has contributed tests for the new features added to XMLHttpRequest Level 2. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] support for streaming data
Hi Charles, Le 10/08/2011 23:19, Charles Pritchard a écrit : On 8/9/2011 1:00 AM, Cyril Concolato wrote: Hi Charles, I believe that GPAC seeks through large SVG files via offsets and small buffers, from what I understood at SVG F2F. http://gpac.wp.institut-telecom.fr/ The technique is similar to what PDF has in it's spec. I don't know what you're referring to. PDF 7.5.8.3 Cross-Reference Stream Data PDF supports byte offsets, links and SMIL. Thanks for the reference. I suppose I was referring more to the MP4Box work than GPAC, though they do work in harmony. MP4 has chunk offsets, and GPAC includes SVG support. I believe that MP4Box stores, and GPAC reads fragments of a large SVG file throughout the MP4 stream, in a limited manner, similar to how a PDF processes streams. They both allow someone to seek and render portions of a large file, without loading it all into memory. From the article: "We have applied the proposed method to fragment SVG content into SVG streams on long-running animated vector graphics cartoons, resulting from the transcoding of Flash content... NHML descriptions were generated automatically by the cartoon or subtitle transcoders." "... the smallest amount of memory [consumed] is the 'Streaming and Progressive Rendering'. The memory consumption peak is reduced by 64%" SVG does not have byte offset hints, but GPAC expects data to be processed by an authoring tool and otherwise works with transcoding, much as VLC (VideoLan) does. The details of how we can do it is here: http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=7129 Basically, for long running SVG animations (e.g. automatic translation from Flash to SVG), it is interesting to load only some SVG parts when they are needed and to discard them (using the SVG Tiny 1.2 element), when they are no longer needed. For that, we use an auxiliary file that indicates how to fragment the SVG file into a stream, giving timestamps to each SVG file fragment. That auxiliary file is then used to store the SVG fragments as regular access units in MP4 files, we use MP4Box for that. The manipulation of those fragments for storage and playback is then similar to what you would do for audio/video streams. We don't do transcoding for SVG fragments but for instance individual gzip encoding is possible. I think an interesting use case for XHR would be to be able to request data with some synchronization, i.e. with a clock reference and timestamp for each response data. Some part of that could be handled via custom HTTP headers; though it's certainly a bit of extra-work, much as implementing "seek" over http can be work. Custom HTTP headers or other HTTP Streaming solutions (e.g. MPEG DASH). That's the benefit of storing the SVG as fragments in an MP4. At the time we wrote the paper we were able to stream the SVG with an unmodified Darwin Streaming Server using the RTP protocol. I believe there would be no problem in streaming the SVG in an MP4 with an unmodified HTTP Server using the DASH approach. I haven't tried though. I'll keep thinking about the case you brought up. I do believe timestamps are currently available on events, relating to when the event was raised. What do you mean by a clock reference? That's a general concept when synchronizing multiple media streams, possibly not all synchronized together, you need to group them by their common clock. Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.institut-telecom.fr/
Re: [XHR] support for streaming data
On 8/10/2011 5:04 PM, Jonas Sicking wrote: The point of streamed XHR is to receive data as soon as it's available so that you can process it right away. This also means that you're likely going to get the data in pretty small chunks. Hence the use cases for streaming are basically the direct opposite of the ones for blobs. I agree. And BlobBuilder is easy to use: there is little need for chunked-blob. It also doesn't make sense for parsed formats, like XML, HTML or, if we add it in the future, JSON, to use streaming. It's unlikely that the contents of those can be delivered in chunks, and so it's better that we'll just incrementally parse, which is already what happens. There are streamed XML formats: SVG and InkML come to mind as possibilities. MP4Box + GPAC lay SVG chunks, and use discard. InkML would be a likely candidate for streaming live sessions. I'm fine with one typed array, 'chunked' == arraybuffer, as I can work from there whether it's text or not. That is, I don't -need- a chunked-text. If I'm streaming, I'm treating the data first and foremost as raw bytes. -Charles
Re: [XHR] support for streaming data
On Mon, Aug 8, 2011 at 9:36 PM, David Flanagan wrote: > On 8/8/11 5:13 PM, Jonas Sicking wrote: >> >> To solve this I propose we add two new values to .responseType: >> "streaming-text" and "streaming-arraybuffer". > > I think this would be a very useful feature. I only have naming nits: > > 1) What do you think of "textstream" instead of "streaming-text"? Similarly > for arraybufferstream (or ArrayBufferStream) That works too. I was actually even thinking "chunked-text" or "chunked-arraybuffer" since this is very different from a real Stream object. (I'm sure we'll eventually add a .responseType="stream"). > 2) Is there any possible use case for streaming blobs? If so, then I'd say > that the streaming vs. non-streaming issue is orthogonal to the data type > issue and there should be something like responseMethod = "stream" instead > of responseType = "streaming-text" I don't think there's a use case for streaming Blobs. The point of a blob is to be able to get large pieces of data which you either don't want to hold in memory all at once, or which you aren't going to use immediately and so you don't want to keep it in memory. The point of streamed XHR is to receive data as soon as it's available so that you can process it right away. This also means that you're likely going to get the data in pretty small chunks. Hence the use cases for streaming are basically the direct opposite of the ones for blobs. It also doesn't make sense for parsed formats, like XML, HTML or, if we add it in the future, JSON, to use streaming. It's unlikely that the contents of those can be delivered in chunks, and so it's better that we'll just incrementally parse, which is already what happens. / Jonas
Re: [XHR] support for streaming data
On 8/9/2011 1:00 AM, Cyril Concolato wrote: Hi Charles, I believe that GPAC seeks through large SVG files via offsets and small buffers, from what I understood at SVG F2F. http://gpac.wp.institut-telecom.fr/ The technique is similar to what PDF has in it's spec. I don't know what you're referring to. PDF 7.5.8.3 Cross-Reference Stream Data PDF supports byte offsets, links and SMIL. I suppose I was referring more to the MP4Box work than GPAC, though they do work in harmony. MP4 has chunk offsets, and GPAC includes SVG support. I believe that MP4Box stores, and GPAC reads fragments of a large SVG file throughout the MP4 stream, in a limited manner, similar to how a PDF processes streams. They both allow someone to seek and render portions of a large file, without loading it all into memory. From the article: "We have applied the proposed method to fragment SVG content into SVG streams on long-running animated vector graphics cartoons, resulting from the transcoding of Flash content... NHML descriptions were generated automatically by the cartoon or subtitle transcoders." "... the smallest amount of memory [consumed] is the 'Streaming and Progressive Rendering'. The memory consumption peak is reduced by 64%" SVG does not have byte offset hints, but GPAC expects data to be processed by an authoring tool and otherwise works with transcoding, much as VLC (VideoLan) does. The details of how we can do it is here: http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=7129 Basically, for long running SVG animations (e.g. automatic translation from Flash to SVG), it is interesting to load only some SVG parts when they are needed and to discard them (using the SVG Tiny 1.2 element), when they are no longer needed. For that, we use an auxiliary file that indicates how to fragment the SVG file into a stream, giving timestamps to each SVG file fragment. That auxiliary file is then used to store the SVG fragments as regular access units in MP4 files, we use MP4Box for that. The manipulation of those fragments for storage and playback is then similar to what you would do for audio/video streams. We don't do transcoding for SVG fragments but for instance individual gzip encoding is possible. I think an interesting use case for XHR would be to be able to request data with some synchronization, i.e. with a clock reference and timestamp for each response data. Some part of that could be handled via custom HTTP headers; though it's certainly a bit of extra-work, much as implementing "seek" over http can be work. I'll keep thinking about the case you brought up. I do believe timestamps are currently available on events, relating to when the event was raised. What do you mean by a clock reference? -Charles
Re: [XHR] support for streaming data
Hi Charles, I believe that GPAC seeks through large SVG files via offsets and small buffers, from what I understood at SVG F2F. http://gpac.wp.institut-telecom.fr/ The technique is similar to what PDF has in it's spec. I don't know what you're referring to. SVG does not have byte offset hints, but GPAC expects data to be processed by an authoring tool and otherwise works with transcoding, much as VLC (VideoLan) does. The details of how we can do it is here: http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=7129 Basically, for long running SVG animations (e.g. automatic translation from Flash to SVG), it is interesting to load only some SVG parts when they are needed and to discard them (using the SVG Tiny 1.2 element), when they are no longer needed. For that, we use an auxiliary file that indicates how to fragment the SVG file into a stream, giving timestamps to each SVG file fragment. That auxiliary file is then used to store the SVG fragments as regular access units in MP4 files, we use MP4Box for that. The manipulation of those fragments for storage and playback is then similar to what you would do for audio/video streams. We don't do transcoding for SVG fragments but for instance individual gzip encoding is possible. I think an interesting use case for XHR would be to be able to request data with some synchronization, i.e. with a clock reference and timestamp for each response data. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.institut-telecom.fr/
Re: [XHR] support for streaming data
On 8/8/11 5:13 PM, Jonas Sicking wrote: To solve this I propose we add two new values to .responseType: "streaming-text" and "streaming-arraybuffer". I think this would be a very useful feature. I only have naming nits: 1) What do you think of "textstream" instead of "streaming-text"? Similarly for arraybufferstream (or ArrayBufferStream) 2) Is there any possible use case for streaming blobs? If so, then I'd say that the streaming vs. non-streaming issue is orthogonal to the data type issue and there should be something like responseMethod = "stream" instead of responseType = "streaming-text" 3) What you propose isn't exactly what I think of as streaming, since there isn't a FIFO buffer involved. I can't get a progress event, read a few bytes of the response and then leave the rest to process at the load event, can I? In this proposal we get one chunk of data per progress event, and that data will be gone when the next progress event arrives, right? Would names like "ChunkedText" and "ChunkedArrayBuffer" more accurately reflect what is going on? Or, if "Chunked" would incorrectly imply some relationship to HTTP chunked encoding, how about "TextFragments" and "ArrayBufferFragments" When .responseType is set to "streaming-text" then during each "progress" event, .response would be set to the text that was received since the last "progress" event (and since the "loadstart" event for the first "progress" event). Same thing when .responseType is set to "streaming-arraybuffer". In this case .response is set to an ArrayBuffer containing the data received since the last "progress" event. There is one non-ideal thing with this solution. Once the last chunk of data has arrived, at least Firefox doesn't fire a "progress" event, but instead just a "load" event. This means that people will have to consume data both from the "progress" event and from the "load" event. Another solution would to make sure to always fire a "progress" event for the last data before firing the "load" event. I personally like this approach more. There *might* even be reasons to do that to ensure that pages create progress bars that reliably reach 100% etc. It seems like it would be important for browsers to do that for these responseTypes, even if they didn't do it for regular "text" and "arraybuffer" responses. / Jonas David
Re: [XHR] support for streaming data
On 8/8/2011 5:59 PM, Jonas Sicking wrote: On Mon, Aug 8, 2011 at 5:48 PM, Charles Pritchard wrote: On 8/8/2011 5:13 PM, Jonas Sicking wrote: Hi All, XHR Level 2 does wonders for making XMLHttpRequest better. However there is one problem that we have run into with "streaming" data. ... Agreed. I proposed something similar in January, with fixed buffer lengths: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0304.html Fixed buffers are somewhat common with more data intense network processing. They may trigger quite a few more progress events, but they guarantee an upper size in memory usage / array length. ... Same thing when .responseType is set to "streaming-arraybuffer". In this case .response is set to an ArrayBuffer containing the data received since the last "progress" event. There is one non-ideal thing with this solution. Once the last chunk of data has arrived, at least Firefox doesn't fire a "progress" event, but instead just a "load" event. This means that people will have to consume data both from the "progress" event and from the "load" event. Another solution would to make sure to always fire a "progress" event for the last data before firing the "load" event. I personally like this approach more. There *might* even be reasons to do that to ensure that pages create progress bars that reliably reach 100% etc. I agree to this, too. For a stream, load may be the same thing as stop, and not have result data. Anne suggested using EventSource and other WebSockets style semantics instead of overloading XHR2. http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0314.html http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0375.html I'd be happy-enough just having a streaming binary buffer. Unless EventSource is dramatically changed, it won't solve the use cases here. One use case that I've brought up several times in the past is incremental loading of Word documents. A more current example would be loading a pdf document and rendering it incrementally as data is coming in. Neither of these cases is even close to how EventSource currently works, so I don't think it's a good fit. Incremental rendering of formats that support it, is certainly a good case. PDF itself, is more complex than Word: Supporting PDF viewer requires HTTP Content-Range to handle offsets in large streams. For efficient PDF support, I'd want to work with something like this: e.response.length == size of data in bytes (array buffer may be larger) e.response.data == array buffer e.response.seek() - method to seek ahead N-bytes before next progress event. Here's a related on File API Streaming Blobs -- this is a valid use case other than crypto, I've posted as su: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0725.html I believe that GPAC seeks through large SVG files via offsets and small buffers, from what I understood at SVG F2F. http://gpac.wp.institut-telecom.fr/ The technique is similar to what PDF has in it's spec. SVG does not have byte offset hints, but GPAC expects data to be processed by an authoring tool and otherwise works with transcoding, much as VLC (VideoLan) does. It seems that a buffer less than 16K could be advantageous on Linux: http://blog.superpat.com/2010/06/01/zero-copy-in-linux-with-sendfile-and-splice/ That'd be helpful for local file viewing, if nothing else. For some authors, it may be helpful to specify the length they're looking to have filled at any one time. -Charles
Re: [XHR] support for streaming data
On Mon, Aug 8, 2011 at 5:48 PM, Charles Pritchard wrote: > On 8/8/2011 5:13 PM, Jonas Sicking wrote: >> >> Hi All, >> >> XHR Level 2 does wonders for making XMLHttpRequest better. However >> there is one problem that we have run into with "streaming" data. > > ... > Agreed. I proposed something similar in January, with fixed buffer lengths: > http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0304.html > > Fixed buffers are somewhat common with more data intense network processing. > They may trigger quite a few more progress events, but they guarantee an > upper > size in memory usage / array length. > ... >> >> Same thing when .responseType is set to "streaming-arraybuffer". In >> this case .response is set to an ArrayBuffer containing the data >> received since the last "progress" event. >> >> There is one non-ideal thing with this solution. Once the last chunk >> of data has arrived, at least Firefox doesn't fire a "progress" event, >> but instead just a "load" event. This means that people will have to >> consume data both from the "progress" event and from the "load" event. >> >> Another solution would to make sure to always fire a "progress" event >> for the last data before firing the "load" event. I personally like >> this approach more. There *might* even be reasons to do that to ensure >> that pages create progress bars that reliably reach 100% etc. >> > I agree to this, too. For a stream, load may be the same thing as stop, and > not have result data. > > Anne suggested using EventSource and other WebSockets style semantics > instead of overloading > XHR2. > http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0314.html > http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0375.html > > I'd be happy-enough just having a streaming binary buffer. Unless EventSource is dramatically changed, it won't solve the use cases here. One use case that I've brought up several times in the past is incremental loading of Word documents. A more current example would be loading a pdf document and rendering it incrementally as data is coming in. Neither of these cases is even close to how EventSource currently works, so I don't think it's a good fit. / Jonas
Re: [XHR] support for streaming data
On 8/8/2011 5:13 PM, Jonas Sicking wrote: Hi All, XHR Level 2 does wonders for making XMLHttpRequest better. However there is one problem that we have run into with "streaming" data. ... Agreed. I proposed something similar in January, with fixed buffer lengths: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0304.html Fixed buffers are somewhat common with more data intense network processing. They may trigger quite a few more progress events, but they guarantee an upper size in memory usage / array length. ... Same thing when .responseType is set to "streaming-arraybuffer". In this case .response is set to an ArrayBuffer containing the data received since the last "progress" event. There is one non-ideal thing with this solution. Once the last chunk of data has arrived, at least Firefox doesn't fire a "progress" event, but instead just a "load" event. This means that people will have to consume data both from the "progress" event and from the "load" event. Another solution would to make sure to always fire a "progress" event for the last data before firing the "load" event. I personally like this approach more. There *might* even be reasons to do that to ensure that pages create progress bars that reliably reach 100% etc. I agree to this, too. For a stream, load may be the same thing as stop, and not have result data. Anne suggested using EventSource and other WebSockets style semantics instead of overloading XHR2. http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0314.html http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0375.html I'd be happy-enough just having a streaming binary buffer. -Charles
Re: [XHR] support for streaming data
On Mon, Aug 8, 2011 at 8:13 PM, Jonas Sicking wrote: > Another solution would to make sure to always fire a "progress" event > for the last data before firing the "load" event. I personally like > this approach more. There *might* even be reasons to do that to ensure > that pages create progress bars that reliably reach 100% etc. > http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0993.html -- Glenn Maynard
