After pondering this over for a few days, here's what I propose.
For an async XHR, if .responseType is set to stream, then when we
reach the HEADERS_RECEIVED state .response is set to a Stream object.
(See more about this below)
As data is being downloaded, we add the data to the end of the
On Fri, Mar 15, 2013 at 10:07 AM, Jonas Sicking jo...@sicking.cc wrote:
For a sync XHR in Workers, if .responseType is set to stream when
XHR.send() is called, we block until the HEADERS_RECEIVED state is
reached. At that point we return from the .send() function and return
a newly constructed
On Mar 15, 2013 5:33 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Mar 15, 2013 at 10:07 AM, Jonas Sicking jo...@sicking.cc wrote:
For a sync XHR in Workers, if .responseType is set to stream when
XHR.send() is called, we block until the HEADERS_RECEIVED state is
reached. At that
On Fri, Mar 15, 2013 at 5:07 AM, Jonas Sicking jo...@sicking.cc wrote:
For an async XHR, if .responseType is set to stream, then when we
reach the HEADERS_RECEIVED state .response is set to a Stream object.
(See more about this below)
As data is being downloaded, we add the data to the end
On Fri, Mar 15, 2013 at 2:36 PM, Glenn Maynard gl...@zewt.org wrote:
I guess we could always make the Stream object immediately produce an
error if .responseType is changed to something other than stream.
Specifically, I'd recommend that when readyState isn't UNSENT, setting
responseType to
On Fri, Mar 15, 2013 at 7:23 PM, Jonas Sicking jo...@sicking.cc wrote:
Specifically, I'd recommend that when readyState isn't UNSENT, setting
responseType to stream should fail, and if readyState is set to
stream
then setting it to something else should fail. That is, once the
request is
On Sat, Mar 9, 2013 at 8:03 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Mar 8, 2013 at 10:40 PM, Jonas Sicking jo...@sicking.cc wrote:
- You could set up an async XHR in one worker, then read it
synchronously
with XHR in another worker. This means the first worker could block the
On Mon, Mar 11, 2013 at 3:03 AM, Jonas Sicking jo...@sicking.cc wrote:
Indeed, returning a Stream from a sync XHR in workers would be fine.
And in that case you should do that as soon as the headers data has
been successfully parsed.
You seem to be saying that synchronous XHR would return
On Fri, Mar 8, 2013 at 10:40 PM, Jonas Sicking jo...@sicking.cc wrote:
But what about the issues I mentioned (you snipped them)? We would be
introducing overlap between XHR and every consumer of URLs
(HTMLImageElement, HTMLVideoElement, CSS loads, CSS subresources, other
XHRs), which
On Thu, Mar 7, 2013 at 9:40 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Mar 7, 2013 at 4:42 PM, Glenn Maynard gl...@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
On Fri, Mar 8, 2013 at 7:52 AM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Mar 7, 2013 at 9:40 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Mar 7, 2013 at 4:42 PM, Glenn Maynard gl...@zewt.org wrote:
The alternative argument is that XHR should represent the data source,
reading data
If we decide to do streaming with the Streams API, the StreamReader API, at
least, seems to need some work. In particular, it seems designed with only
binary protocols that specify block sizes in mind. It can't handle textual
protocols at all. For example, it couldn't be used to parse a
On Thu, Mar 7, 2013 at 4:42 PM, Glenn Maynard gl...@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
On Tue, Feb 26, 2013 at 7:53 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Feb 26, 2013 at 4:56 AM, Anne van Kesteren ann...@annevk.nlwrote:
The advantage the Streams API seems to have over moz-blob is that you
do not need to create a new object to read from each time there's
fresh data.
On Thu, Feb 28, 2013 at 7:07 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
Also, the Stream object lets you pipe the data from to/from Web Workers,
which can be handy in certain scenarios.
Hey Travis, could you maybe reply to my original or at least some of
the earlier emails that
On Wed, Feb 27, 2013 at 10:03 PM, Cyril Concolato
cyril.concol...@telecom-paristech.fr wrote:
I was confused when reading only:
The arraybuffer response entity body is an ArrayBuffer representing the
response entity body.
and then:
The response entity body is the fragment of the entity body
On Thu, Feb 28, 2013 at 12:13 AM, Darin Fisher da...@chromium.org wrote:
It's a fair question, and I think you've made a lot of good points. I
think XHR gives you the ability to customize the HTTP request. You can set
custom request headers, customize the request method, control cross-origin
On Wed, Feb 27, 2013 at 5:26 PM, Glenn Maynard gl...@zewt.org wrote:
I'm simply asking: what use cases there are for creating a stream with XHR
and handing the stream off to another API, that can't be done much more
simply by handing a URL to the other API in the first place?
I've trimmed
On 2013-02-27 02:55, Glenn Maynard wrote:
What are some actual use cases? I don't think any have been
mentioned on this thread.
- I would like to stream realtime TV. Pausing shouldn't be a problem
because I don't rely on POST requests and I would just buffer up to a
certain limit.
- Another
On Wed, Feb 27, 2013 at 12:02 AM, Darin Fisher da...@chromium.org wrote:
I assume that even if the Stream is not done downloading that it should be
safe to reuse the XHR object that provided the Stream, right? Hmm, I can
imagine some implementation complexity arising from saying that a XHR is
On Wed, Feb 27, 2013 at 7:24 AM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Feb 27, 2013 at 12:02 AM, Darin Fisher da...@chromium.org wrote:
I assume that even if the Stream is not done downloading that it should
be safe to reuse the XHR object that provided the Stream, right? Hmm, I
can
On Tue, Feb 26, 2013 at 5:55 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Feb 26, 2013 at 7:16 PM, Darin Fisher da...@chromium.org wrote:
Interesting idea, but what is the motivation for this change? Why would
the XHR (data provider) state machine need to change?
XHR is a consumer, not
On Wed, Feb 27, 2013 at 7:24 AM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Feb 27, 2013 at 12:02 AM, Darin Fisher da...@chromium.org wrote:
I assume that even if the Stream is not done downloading that it should
be safe to reuse the XHR object that provided the Stream, right? Hmm, I
can
On Wed, Feb 27, 2013 at 8:54 AM, Aaron Colwell acolw...@chromium.orgwrote:
On Tue, Feb 26, 2013 at 5:55 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Feb 26, 2013 at 7:16 PM, Darin Fisher da...@chromium.org wrote:
Interesting idea, but what is the motivation for this change? Why would
Hi Anne,
Le 26/02/2013 17:34, Anne van Kesteren a écrit :
On Tue, Feb 26, 2013 at 3:01 PM, Cyril Concolato
cyril.concol...@telecom-paristech.fr wrote:
Hi Anne,
Did you mean to reply just to me?
No, adding the list.
* moz-blob
Is this the same as blob specified in the XHR2 draft [1]?
On Wed, Feb 27, 2013 at 10:39 AM, Aaron Colwell acolw...@chromium.orgwrote:
- I would like to stream realtime TV. Pausing shouldn't be a problem
because I don't rely on POST requests and I would just buffer up to a
certain limit.
- Another use case that comes to mind is starting to watch
On Wed, Feb 27, 2013 at 5:26 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Feb 27, 2013 at 10:39 AM, Aaron Colwell acolw...@chromium.orgwrote:
- I would like to stream realtime TV. Pausing shouldn't be a problem
because I don't rely on POST requests and I would just buffer up to a
certain
Also, the Stream object lets you pipe the data from to/from Web Workers, which
can be handy in certain scenarios.
From: da...@google.com [mailto:da...@google.com] On Behalf Of Darin Fisher
[snip]
Another thing not to lose sight of is that a Stream abstraction could be useful
as an optimization
So currently Mozilla has these extensions to XMLHttpRequest:
* moz-blob
* moz-chunked-text
* moz-chunked-arraybuffer
The first offers incremental read. The latter two offer chunked read
(data can be discarded as soon as it's read).
There's also Microsoft's Streams API which I added to the
On Tue, Feb 26, 2013 at 4:56 AM, Anne van Kesteren ann...@annevk.nl wrote:
The advantage the Streams API seems to have over moz-blob is that you
do not need to create a new object to read from each time there's
fresh data. The disadvantage is that that's only a minor advantage and
there's a
On Tue, Feb 26, 2013 at 3:53 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Feb 26, 2013 at 4:56 AM, Anne van Kesteren ann...@annevk.nl wrote:
I suppose a use case would be making a POST request or a request with
special headers set to access a video stream. You can createObjectURL on
the
On Tue, Feb 26, 2013 at 8:38 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Feb 26, 2013 at 3:53 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Feb 26, 2013 at 4:56 AM, Anne van Kesteren ann...@annevk.nl
wrote:
I suppose a use case would be making a POST request or a request with
On Tue, Feb 26, 2013 at 4:50 PM, Aaron Colwell acolw...@chromium.org wrote:
One other data point is that we are using the Stream as an opaque handle for
routing data to the Media Source Extensions. (See
SourceBuffer.appendStream()). The idea here is that it allows the data from
an XHR to be
On Tue, Feb 26, 2013 at 10:38 AM, Anne van Kesteren ann...@annevk.nlwrote:
We can get chunked reads without an additional mode. Just add an
additional method, eg. clearResponse, which empties .response. This would
work for all modes that support incremental reads. For Blobs, this would
On Tue, Feb 26, 2013 at 9:12 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Feb 26, 2013 at 4:50 PM, Aaron Colwell acolw...@chromium.org
wrote:
One other data point is that we are using the Stream as an opaque handle
for
routing data to the Media Source Extensions. (See
On Tue, Feb 26, 2013 at 11:12 AM, Anne van Kesteren ann...@annevk.nlwrote:
Okay, so we want to keep something like Stream around. Do you need a
Blob without size kind of object? E.g. that would mean it cannot have
chunked semantics (the stuff you read is thrown away), which is
something we
On Tue, Feb 26, 2013 at 9:40 AM, Aaron Colwell acolw...@chromium.orgwrote:
On Tue, Feb 26, 2013 at 9:12 AM, Anne van Kesteren ann...@annevk.nlwrote:
On Tue, Feb 26, 2013 at 4:50 PM, Aaron Colwell acolw...@chromium.org
wrote:
One other data point is that we are using the Stream as an opaque
On Tue, Feb 26, 2013 at 5:10 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Feb 26, 2013 at 11:12 AM, Anne van Kesteren ann...@annevk.nlwrote:
Okay, so we want to keep something like Stream around. Do you need a
Blob without size kind of object? E.g. that would mean it cannot have
chunked
On Tue, Feb 26, 2013 at 7:16 PM, Darin Fisher da...@chromium.org wrote:
Interesting idea, but what is the motivation for this change? Why would
the XHR (data provider) state machine need to change?
XHR is a consumer, not a provider: it consumes data from the HTTP stream
and returns it in one
On Tue, Feb 26, 2013 at 5:55 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Feb 26, 2013 at 7:16 PM, Darin Fisher da...@chromium.org wrote:
Interesting idea, but what is the motivation for this change? Why would
the XHR (data provider) state machine need to change?
XHR is a consumer, not
40 matches
Mail list logo
