RE: new draft of recording proposal

Responses in-line

-----Original Message-----
From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com] 
Sent: Friday, January 04, 2013 8:34 AM
To: Jim Barnett
Cc: public-media-capture@w3.org
Subject: 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?

>> Yes, I'll make that change

 > 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.

>> I agree we should align.  Does anyone else have an opinion on whether the names should  include  'recording' or not?

 > 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.

>> Thanks, I'll fix that.  

 > 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).

>> Yes, I agree that we don't need the Stream in the event. (We do need the Track in the mute/unmute events, though) 

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

/Adam

Received on Friday, 4 January 2013 14:03:15 UTC