RE: Expect behavior of calling stop before receiving the onstart event on MediaRecorder API?

Harald,
  Task B is not waiting for an external event.  It is queued waiting for task A to complete.  Once A completes, B takes over the single thread.  

- Jim

-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Monday, December 09, 2013 7:40 AM
To: Jim Barnett; Randy Lin
Cc: public-media-capture@w3.org
Subject: Re: Expect behavior of calling stop before receiving the onstart event on MediaRecorder API?

On 12/05/2013 03:52 AM, Jim Barnett wrote:
> Randy,
>    The queuing behavior will be whatever the HTML specification requires.  If tasks A and B are put in the same queue, I would assume (given the normal meaning of 'queue') that means that B does not execute until A completes, but please educate me if the HTML spec says something different.

My understanding of the HTML event model is that essentially nothing happens while a task is executing (it's a single-threaded model), so a task waiting for something will essentially halt the browser.

If the spec says that a task should wait for an external event, I think the spec needs to change.

>
> - Jim
>
> -----Original Message-----
> From: Randy Lin [mailto:rlin@mozilla.com]
> Sent: Wednesday, December 04, 2013 8:57 PM
> To: Jim Barnett
> Cc: public-media-capture@w3.org
> Subject: Re: Expect behavior of calling stop before receiving the onstart event on MediaRecorder API?
>
> Hi Jim,
> About the start method
> "Set state to 'recording' and wait until media becomes available from stream."
> The stream available waiting time may not be estimated and it is possible that application want to cancel the recording operation during that time.
> Does the stop method should in waiting queue until the start tasks finished?
> That means stop method can be executed after onstart event fired.
>
> -------------------------------------
> -rlin
>
> ----- Original Message -----
> From: "Jim Barnett" <Jim.Barnett@genesyslab.com>
> To: "Randy Lin" <rlin@mozilla.com>, public-media-capture@w3.org
> Sent: Thursday, December 5, 2013 12:33:36 AM
> Subject: RE: Expect behavior of calling stop before receiving the onstart  event  on MediaRecorder API?
>
> Randy,
>    I'm not sure why the UA would call stop().  I would expect the application to do it.  But in any case, the behavior should be as follows:  both start() and stop() queue tasks, so the stop() method's task will not be executed before the start task completes.  One of the first things that the start task does is to set the state to 'recording'.  At the time the stop task executes, it is true that the start event may not have been processed, but the state will be 'recording' and the stop task will execute and fire the dataavailable and stop events.  The only time that the stop task would raise an error would be if the recorder was in the wrong state.
>
> - Jim
>
> -----Original Message-----
> From: Randy Lin [mailto:rlin@mozilla.com]
> Sent: Wednesday, December 04, 2013 3:26 AM
> To: public-media-capture@w3.org
> Subject: Expect behavior of calling stop before receiving the onstart event on MediaRecorder API?
>
> Hi all,
> Refer this API document.
> https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/MediaReco

> rder.html
> What's the expect behavior if
> UA try to call the stop method before receiving the onstart event on MediaRecorder API.
> Should we queue this stop() task after onstart event or throw exception on stop method invoked or cancel the recording task and fire the events which stop() method required?
> -------------------------------------
> -rlin

Received on Monday, 9 December 2013 13:29:15 UTC