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
can i ask, how do you use the abort event handler?
and error event handler
In jQuery 1.x, we don't even use onsuccess, onerror and onabort. Reason
being onreadystatechange is the only cross-browser means to handle
XMLHttpRequest when you have to support old IEs (and we try and avoid
having
On Fri, Feb 22, 2013 at 2:42 AM, Alex Mogilevsky alex...@microsoft.com wrote:
Thanks for background, it helps a lot. I don't see a need to comment it by
point so let me just reference it [1] and try to summarize.
1. There is no consensus on what the default should be. There are
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
Hi Art, slightly late response because I've been away.
CCing public-webapps on this reply, in case anyone knows more that should be
done.
I would like to know your thoughts and plans for the Clipboard API spec.
Here's a short summary as I see it ...
* The last publication of Clipboard
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 2:51 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
On Mon, Feb 25, 2013 at 9:46 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/25/13 12:33 PM, Tab Atkins Jr. wrote:
If a script is explicitly looking inside the shadows of unknown
controls and checking their
On Tue, Feb 26, 2013 at 10:44 AM, Dominic Cooney domin...@chromium.org wrote:
Although the default provided by the spec is important, early adopters are
also important in shaping practice. There is apparently strong conviction on
both sides of the argument. If shadows are public by default,
On 2/26/13 1:57 PM, Tab Atkins Jr. wrote:
An argument to the contrary (which you do seem to acknowledge later in
your message, if I'm reading correctly): if you make shadow private,
but allow authors to make them public on an ad-hoc basis
I think ad-hoc in this case means per-component, not
Also, if shadows are public by default the API to access the shadow is well
defined. If shadows are private by default and components decide to expose
the shadow ad hoc then there is no standardized API.
On Feb 26, 2013 1:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Feb 26, 2013 at
On Wed, Feb 27, 2013 at 4:05 AM, Erik Arvidsson a...@google.com wrote:
Also, if shadows are public by default the API to access the shadow is
well defined. If shadows are private by default and components decide to
expose the shadow ad hoc then there is no standardized API.
See below.
On
On Wed, Feb 27, 2013 at 4:03 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/26/13 1:57 PM, Tab Atkins Jr. wrote:
An argument to the contrary (which you do seem to acknowledge later in
your message, if I'm reading correctly): if you make shadow private,
but allow authors to make them public
On 2/26/13 3:56 PM, Dominic Cooney wrote:
One more thought occurs to me: It is easier to add public shadows in a
subsequent revision of the spec than it is to take public shadows away.
Yes, indeed. That's one of the main reasons I'd like it to be the
initial default...
I would certainly be
On Tue, Feb 26, 2013 at 11:05 AM, Erik Arvidsson a...@google.com wrote:
Also, if shadows are public by default the API to access the shadow is well
defined. If shadows are private by default and components decide to expose
the shadow ad hoc then there is no standardized API.
This doesn't have
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
23 matches
Mail list logo
