Re: new draft of recording proposal

On 2012-12-20 19:15, Jim Barnett wrote:
> If anyone is looking for an excuse to escape from their relatives over
> the holidays, they might try reviewing the updated recording proposal.
> I have aligned the event and error definitions with the other specs,
> added pause/resume, mute/unmute, and Travis’ photo proposal.
>
> The main remaining work item is to fix the get/set parameters syntax and
> use a Mime type instead of separate entries for the various codecs.
> I’ll try to work on that when it becomes time to escape from my relatives.
>
> -Jim
>

This looks really good. I'm a bit uncertain about all the track muting 
stuff, but lets see what happens with the enabled attribute on MediaStream.

 > readonly attribute MediaStream mediaStream;

Nit: Could we go with just "stream" here to align with the other two 
specs where we leave out the "media" part in function/attribute and 
argument names?

 > void stopRecording ();
  void pause();
  void resume();

Could we align these names. Either have the "Recording" suffix on all or 
none. I think we could skip it since what we're stopping or pausing is 
given by the context of the object being a MediaStreamRecorder.

 > Note that the Blob (see FILEAPI) of recorded data is contained in 
this event and can be accessed via the 'detail' attribute.

This text applies to a CustomEvent, but now we're using a BlobEvent.

 > recording 	MediaSteamEvent
stoprecording 	MediaSteamEvent
pause 	MediaSteamEvent
resume 	MediaSteamEvent

Could we use the simple Event type for these? I don't see the need to 
include the MediaStream in these events. The stream is accessible via 
the recorder (which is exposed as the "target" attribute on the event).

(I wrote is is a separate discussion, but I include it here as well for 
completeness.)

/Adam

Received on Friday, 4 January 2013 13:34:01 UTC