+Aaron
On Thu, Sep 11, 2014 at 6:48 PM, Aymeric Vitte
wrote:
> But I suppose that should be one of the first use case for Google to
> introduce streams with MSE, no?
>
>
We're (and will) sharing updates about Streams with MSE folk (Aaron). MSE
side would be updated once Streams API becomes stab
But I suppose that should be one of the first use case for Google to
introduce streams with MSE, no?
To be more clear about what I mean by "back pressure for things coming
from outside of the browser":
- XHR: the Streams API should define how xhr gets chunks using Range
according to the flow
On Thu, Sep 11, 2014 at 8:47 AM, Aymeric Vitte
wrote:
> Does your experimentation pipe the XHR stream to MSE? Obviously that
> should be the target for yt, this would be a first real application of the
> Streams API.
>
It's not yet updated to use the new Streams. Here's our layout test for
MSE.
Does your experimentation pipe the XHR stream to MSE? Obviously that
should be the target for yt, this would be a first real application of
the Streams API.
Because the Streams API does not define how to apply back pressure to
XHR, but does define how to apply back pressure between XHR and MSE
On Thu, Sep 4, 2014 at 7:02 AM, Aymeric Vitte
wrote:
> The fact is that most of the W3C groups impacted by streams (File,
> indexedDB, MSE, WebRTC, WebCrypto, Workers, XHR, WebSockets, Media Stream,
> etc, I must forget a lot here) seem not to care a lot about it and maybe
> just expect streams t
On Thu, Sep 4, 2014 at 12:02 AM, Aymeric Vitte wrote:
> Sorry to interfer then but your discussion with Arun seems to have no point
> if streams are there.
I don't follow.
> The fact is that most of the W3C groups impacted by streams (File,
> indexedDB, MSE, WebRTC, WebCrypto, Workers, XHR, Web
Arun,
I know you (File API) care about it, I was more refering to other groups
that seem not to care a lot, leading to absurd situations where we are
streaming things without streams and have to implement some strange
inadapted mechanisms for flow control/backpressure for example.
The exampl
On Sep 3, 2014, at 6:02 PM, Aymeric Vitte wrote:
>
> The fact is that most of the W3C groups impacted by streams (File, indexedDB,
> MSE, WebRTC, WebCrypto, Workers, XHR, WebSockets, Media Stream, etc, I must
> forget a lot here) seem not to care a lot about it and maybe just expect
> streams
On Aug 11, 2014, at 7:24 AM, Anne van Kesteren wrote:
>
>> Other than “chunks of bytes” which needs some normative backbone, is the
>> basic abstract model what you had in mind? If so, that might be worth
>> getting into File APi and calling it done, because that’s a reusable
>> abstract mode
Sorry to interfer then but your discussion with Arun seems to have no
point if streams are there.
But some points I mentioned have, whether it's really linked to the
initial subject or not.
The fact is that most of the W3C groups impacted by streams (File,
indexedDB, MSE, WebRTC, WebCrypto,
On Thu, Aug 28, 2014 at 2:15 AM, Aymeric Vitte wrote:
> I have contributed to streams already, of course it will solve most of what
> is being discussed here but when? And then what's the point of this
> discussion?
This discussion between me and Arun is about how to describe various
algorithms i
I have contributed to streams already, of course it will solve most of
what is being discussed here but when? And then what's the point of this
discussion?
But maybe it will not solve everything, like my indexedDB example, which
is not even considered in indexedDB V2 as far as I know
Le 25/0
On Sun, Aug 24, 2014 at 11:59 PM, Aymeric Vitte wrote:
> File, XHR and indexedDB should handle partial data, I thought I understood
> from messages last year that it was clearly identified as a mistake.
This will be solved with streams. I recommend contributing to
https://github.com/whatwg/stream
Back in this thread lately too...
I still don't see how you intend to solve the use case I gave:
- load 'something' progressively, get chunks (should be possible via xhr
but it's not)
- handle it via File augmenting the related Blob (not possible) and
store it progressively in indexedDB (not p
On Fri, Aug 8, 2014 at 5:56 PM, Arun Ranganathan wrote:
> I strongly think we should leave FileReaderSync and FileReader alone. Also
> note that FileReaderSync and XHR (sync) are not different, in that both don’t
> do partial data. But we should have a stream api that evolves to read, and it
>
Welcome back - we missed you :-)
On Aug 5, 2014, at 9:43 AM, Anne van Kesteren wrote:
> On Thu, Jul 17, 2014 at 2:58 PM, Arun Ranganathan wrote:
>> There are two questions:
>>
>> 1. How should FileReaderSync behave, to solve the majority of use cases?
>> 2. What is a useful underlying abstrac
Sorry for the late response Arun. I blame vacation and not being quite
sure how we should solve this taking into account the legacy
consumers.
On Thu, Jul 17, 2014 at 2:58 PM, Arun Ranganathan wrote:
> There are two questions:
>
> 1. How should FileReaderSync behave, to solve the majority of use
Aymeric,
(Sorry for the delay; I was traveling for the last part of July.)
On Jul 17, 2014, at 11:25 AM, Aymeric Vitte wrote:
> I don't get this, most reads inside browsers are about fetching, and fetching
> does increment a resource while it is loaded/displayed (image, video, crypto
> opera
Aymeric,
(Sorry for the delay; I was traveling for the last part of July.)
On Jul 17, 2014, at 11:25 AM, Aymeric Vitte wrote:
> I don't get this, most reads inside browsers are about fetching, and fetching
> does increment a resource while it is loaded/displayed (image, video, crypto
> opera
Arun,
Streams will solve this, assuming they are implemented by all related
APIs (this is not obvious, most of WGs seem not to care at all now that
they have implemented their own so-called streams)
Quoting your other answer:
Well, the bug that removed them
is:https://www.w3.org/Bugs/Public
Aymeric,
On Jul 16, 2014, at 8:20 AM, Aymeric Vitte wrote:
> Example:
> var myfile=new Blob();
>
> //chunks are coming in
> myfile=new Blob([myfile,chunk],...)
>
> //mylink A tag
> mylink.href=URL.createObjectURL(myfile)
>
> click on mylink --> does not work
>
> Expected behavior: the file (
On Jul 14, 2014, at 3:47 AM, Anne van Kesteren wrote:
> On Thu, Jul 10, 2014 at 7:05 PM, Arun Ranganathan wrote:
>> On Jul 3, 2014, at 10:50 AM, Anne van Kesteren wrote:
>>> That would mean you would get different results between using
>>> FileReaderSync and XMLHttpRequest. That does not seem i
Le 10/07/2014 19:05, Arun Ranganathan a écrit :
We agreed some time ago to not have partial data.
I still think that's a big mistake. Even if the Streams API will solve
this, this should be corrected in the File API.
Unless I am misusing the API, you can not even increment a Blob, you
have
On Thu, Jul 10, 2014 at 7:05 PM, Arun Ranganathan wrote:
> On Jul 3, 2014, at 10:50 AM, Anne van Kesteren wrote:
>> That would mean you would get different results between using
>> FileReaderSync and XMLHttpRequest. That does not seem ideal
>
> The implementation train has already left the statio
On Jul 3, 2014, at 10:50 AM, Anne van Kesteren wrote:
> On Thu, Jul 3, 2014 at 4:29 PM, Arun Ranganathan wrote:
>> OK, this is fixable. I’ll ensure that the read operation’s synchronous
>> component does return the results thus far, but that FIleReaderSync itself
>> ignores them in case of a mid
On Thu, Jul 3, 2014 at 4:29 PM, Arun Ranganathan wrote:
> OK, this is fixable. I’ll ensure that the read operation’s synchronous
> component does return the results thus far, but that FIleReaderSync itself
> ignores them in case of a midstream error, unless we collectively agree that
> it SHOULD r
On Jul 3, 2014, at 10:17 AM, Anne van Kesteren wrote:
> So most of Fetch is asynchronous. If it's invoked with the synchronous
> flag set it's just that it waits for the entire response before
> returning. That's why I'd like to use the asynchronous path of reading
> a blob. But I'd like that no
On Thu, Jul 3, 2014 at 3:58 PM, Arun Ranganathan wrote:
> You’ve since changed your mind, which is totally fine
I wish I could foresee all problems before starting to write things
out, that'd be great! :-)
> but overhauling the current read operation for a change
> of mind/model is a lot of pai
On Jul 3, 2014, at 4:14 AM, Anne van Kesteren wrote:
> It's unclear to me why we'd want to use the event loop for this,
> basically.
The FileReader object uses the event loop; your initial request for Fetch was
to have a reusable “abstract” read operation which used tasks. You’ve since
chang
On Wed, Jul 2, 2014 at 7:06 PM, Arun Ranganathan wrote:
> For instance, I thought the idea was that within Fetch to read /blob/ we’d
> do something like:
>
> 1. Let /s/ be a new body. Return /s/ and perform the rest of the steps
> async.
> 2. Perform a read operation [File API] on /blob/.
> 3. To
I am a little unclear as to what you are trying to accomplish here.
>From my perspective streams are not really an abstract concept, but instead
>are specific JavaScript APIs that conform to a given contract. In contrast, an
>underlying source [1] is an abstract concept; a given (readable) strea
On Jul 2, 2014, at 10:28 AM, Anne van Kesteren wrote:
> So what I need is something like this:
>
> To read a Blob object /blob/, run these steps:
>
> 1. Let /s/ be a new body. [FETCH]
>
> 2. Return /s/, but continue running these steps asynchronously.
>
> 3. While /blob/'s underlying data
32 matches
Mail list logo
