Re: new draft of recording

For the RecordingErrorNameEnum & RecordingExceptionEnum webIDL, 
Could we let the naming style to like the DOMError naming?
ie "INVALID_STATE" vs "InvalidStateError"
BTW, what's the purpose for adding the interface:RecordingError? 
Is let UA can get the detail message from mediaRecorder object and limit the naming type of RecordingError?
---
Randy

----- Original Message -----
From: "Robert O'Callahan" <robert@ocallahan.org>
To: "Jim Barnett" <Jim.Barnett@genesyslab.com>
Cc: "Travis Leithead" <travis.leithead@microsoft.com>, public-media-capture@w3.org
Sent: Wednesday, April 3, 2013 4:14:59 AM
Subject: Re: new draft of recording


On Wed, Apr 3, 2013 at 12:43 AM, Jim Barnett < Jim.Barnett@genesyslab.com > wrote: 













OK I guess. What about stop, pause and resume? 


>> They’re part of the same use case that Travis described – letting the UI provide feedback about when recording is actually happening. 


The thing is that, bearing in mind the firing of the events can be delayed, they're not perfectly accurate anyway. So are you saying that in typical implementations, there *has to be* a long (order of seconds, I guess) delay between calling pause() and recording actually pausing? And ditto for resuming and stopping? 





















At one of our prior F2F meetings, one of the use cases for warnings was to alert the user if the inbound stream configuration changes in such a way that could still be supported by the recorder, but might be something the code would want to respond to. For example, new tracks being added/removed while recording. 





That's covered by track add/remove events already specced on MediaStreams. 

>> It’s a more complicated case than that. Whether a track can be added to a recording that’s underway depends on the track type and the mime type. So the add/remove track events are not sufficient by themselves. 



Then I think we should have a specific API for that which allows the app to determine which track(s) aren't being recorded. It could be a specific unsupportedtrack event, or we could let the app listen for the addition of a new track, and provide an API on the StreamRecorder to check whether a MediaStreamTrack is being recorded by the recording. Maybe the latter is better since it would also be useful for the case where a newly-created StreamRecorder can't record all the existing tracks. 

Rob 
-- 
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q q Aqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"

Received on Friday, 12 April 2013 09:23:31 UTC