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
XML
On Tue, Feb 26, 2013 at 4:56 AM, Anne van Kesteren 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 whole lot of ne
On Tue, Feb 26, 2013 at 3:53 PM, Glenn Maynard wrote:
> On Tue, Feb 26, 2013 at 4:56 AM, Anne van Kesteren 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 resulting Stream and pass tha
On Tue, Feb 26, 2013 at 8:38 AM, Anne van Kesteren wrote:
> On Tue, Feb 26, 2013 at 3:53 PM, Glenn Maynard wrote:
> > On Tue, Feb 26, 2013 at 4:56 AM, Anne van Kesteren
> wrote:
> > I suppose a use case would be making a POST request or a request with
> > special headers set to access a video s
On Tue, Feb 26, 2013 at 4:50 PM, Aaron Colwell 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 transferred to the S
On Tue, Feb 26, 2013 at 10:38 AM, Anne van Kesteren wrote:
> > 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
> > cause
On Tue, Feb 26, 2013 at 9:12 AM, Anne van Kesteren wrote:
> On Tue, Feb 26, 2013 at 4:50 PM, Aaron Colwell
> 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
On Tue, Feb 26, 2013 at 11:12 AM, Anne van Kesteren wrote:
> 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 probably want
On Tue, Feb 26, 2013 at 9:40 AM, Aaron Colwell wrote:
>
> On Tue, Feb 26, 2013 at 9:12 AM, Anne van Kesteren wrote:
>
>> On Tue, Feb 26, 2013 at 4:50 PM, Aaron Colwell
>> wrote:
>> > One other data point is that we are using the Stream as an opaque
>> handle for
>> > routing data to the Media Sou
On Tue, Feb 26, 2013 at 5:10 PM, Glenn Maynard wrote:
> On Tue, Feb 26, 2013 at 11:12 AM, Anne van Kesteren wrote:
>
>> 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
On Tue, Feb 26, 2013 at 7:16 PM, Darin Fisher 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 form or another
On Tue, Feb 26, 2013 at 5:55 PM, Glenn Maynard wrote:
> On Tue, Feb 26, 2013 at 7:16 PM, Darin Fisher 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 consume
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 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
> done before t
On Wed, Feb 27, 2013 at 7:24 AM, Glenn Maynard wrote:
> On Wed, Feb 27, 2013 at 12:02 AM, Darin Fisher 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 implementatio
On Tue, Feb 26, 2013 at 5:55 PM, Glenn Maynard wrote:
> On Tue, Feb 26, 2013 at 7:16 PM, Darin Fisher 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 consume
On Wed, Feb 27, 2013 at 7:24 AM, Glenn Maynard wrote:
> On Wed, Feb 27, 2013 at 12:02 AM, Darin Fisher 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 implementatio
On Wed, Feb 27, 2013 at 8:54 AM, Aaron Colwell wrote:
>
>
>
> On Tue, Feb 26, 2013 at 5:55 PM, Glenn Maynard wrote:
>
>> On Tue, Feb 26, 2013 at 7:16 PM, Darin Fisher wrote:
>>
>>> Interesting idea, but what is the motivation for this change? Why would
>>> the XHR (data provider) state machine
Hi Anne,
Le 26/02/2013 17:34, Anne van Kesteren a écrit :
On Tue, Feb 26, 2013 at 3:01 PM, Cyril Concolato
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]?
No, it's available during LOADING.
On Wed, Feb 27, 2013 at 10:39 AM, Aaron Colwell wrote:
> - 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 a video
>>>
On Wed, Feb 27, 2013 at 5:26 PM, Glenn Maynard wrote:
> On Wed, Feb 27, 2013 at 10:39 AM, Aaron Colwell wrote:
>
>> - 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.
>>>
>>> - Anot
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
On Thu, Feb 28, 2013 at 7:07 AM, Travis Leithead
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 discuss the semantics of Strea
On Wed, Feb 27, 2013 at 10:03 PM, Cyril Concolato
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 of the response
> received so
On Thu, Feb 28, 2013 at 12:13 AM, Darin Fisher 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
> behavior, etc
On Wed, Feb 27, 2013 at 5:26 PM, Glenn Maynard 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 off the rest
On Tue, Feb 26, 2013 at 7:53 AM, Glenn Maynard wrote:
> On Tue, Feb 26, 2013 at 4:56 AM, Anne van Kesteren 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 tha
On Tue, Feb 26, 2013 at 2:56 AM, Anne van Kesteren wrote:
> 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 i
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 keepaliv
On Thu, Mar 7, 2013 at 4:42 PM, Glenn Maynard 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 t
On Thu, Mar 7, 2013 at 9:40 PM, Jonas Sicking wrote:
> On Thu, Mar 7, 2013 at 4:42 PM, Glenn Maynard 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 i
On Fri, Mar 8, 2013 at 7:52 AM, Glenn Maynard wrote:
> On Thu, Mar 7, 2013 at 9:40 PM, Jonas Sicking wrote:
>>
>> On Thu, Mar 7, 2013 at 4:42 PM, Glenn Maynard wrote:
>> > The alternative argument is that XHR should represent the data source,
>> > reading data from the network and pushing it to
On Fri, Mar 8, 2013 at 10:40 PM, Jonas Sicking 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 could each m
On Sat, Mar 9, 2013 at 8:03 AM, Glenn Maynard wrote:
> On Fri, Mar 8, 2013 at 10:40 PM, Jonas Sicking 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
>> > second worker at will
On Mon, Mar 11, 2013 at 3:03 AM, Jonas Sicking 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 at LOADING, th
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 Str
On Fri, Mar 15, 2013 at 10:07 AM, Jonas Sicking 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 Stream obj
On Mar 15, 2013 5:33 AM, "Anne van Kesteren" wrote:
>
> On Fri, Mar 15, 2013 at 10:07 AM, Jonas Sicking 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 t
On Fri, Mar 15, 2013 at 5:07 AM, Jonas Sicking 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 of the Stre
On Fri, Mar 15, 2013 at 2:36 PM, Glenn Maynard 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 "stream
On Fri, Mar 15, 2013 at 7:23 PM, Jonas Sicking 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
> >
41 matches
Mail list logo
