RE: new draft of recording proposal

I have removed 'recording' from the names in the current draft.

- Jim

-----Original Message-----
From: Travis Leithead [mailto:travis.leithead@microsoft.com] 
Sent: Monday, January 07, 2013 1:27 PM
To: Jim Barnett; Adam Bergkvist
Cc: public-media-capture@w3.org
Subject: RE: new draft of recording proposal

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

The 'recording' suffix was original present because this interface mixed-in to the MediaStream interface (which already had a "stop") API. Since we've now agreed that recording is accomplished on a separate object, then I agree that we should simply and drop the "recording" suffix.


> -----Original Message-----
> From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
> Sent: Friday, January 4, 2013 6:03 AM
> To: Adam Bergkvist
> Cc: public-media-capture@w3.org
> Subject: 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 Monday, 7 January 2013 18:32:38 UTC