RE: new draft of recording proposal

Giri, did you get any feedback on your proposal?

Jim, great stuff! Some suggestions for improvement:

*         I think you've duplicated functionality that's already available on the track level with "muteTrack" and "unmuteTrack". Apparently, MediaStreamTrack's "enabled" boolean switch already does this. I don't believe the sink needs to have this capability-unless we're talking about removing the "enabled" switch from the MediaStreamTrack...

*         takePhoto is defined to throw when the recorder is not "recording". Is this a requirement for takePhoto? I would think that as long as the underlying track's readyState is "live", then takePhoto would succeed (and that it wouldn't be necessary to start recording to call this API).

*         You've also defined takePhoto to throw if the underlying track source isn't "photo-camera". This seems OK to me, but it implies that the source will have a photo-mode. Thus you'd probably never expect a frame grab. Now, if the source was just "camera", then you might expect this to happen, but then you would have thrown an exception earlier. Perhaps you can relax the throw conditions to a track of type VideoStreamTrack only.

*         You're using the old syntax for throwing exceptions. Last year, the syntax was updated in WebIDL<http://dev.w3.org/2006/webapi/WebIDL/v1.html#idl-exceptions>. You can see examples of how to do this in DOM4 (http://www.w3.org/TR/dom/#error-names-0). Basically, you now say: "throw a DOMException with name InvalidTrackIdError". (INVALID_TRACK_ID --> InvalidTrackId + "Error" on the end).

*         I think you should get rid of "RecordingError" and adopt the de-facto way of reporting errors asynchronously that has been used in IndexedDb<http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBRequest-error>, FileReader<http://dev.w3.org/2006/webapi/FileAPI/#ErrorAndException>, etc: namely the "DOMError<http://www.w3.org/TR/dom/#interface-domerror>" object defined in DOM4. Basically, you just create a new attribute of type DOMError? error, which is null unless an error state has been set, in which case the DOMError basically mirrors the error exception names. You can still fire a "recordingerror" event, but the interface will be Event, instead of "RecordingError" as presently defined. I suggest reading through the IndexedDb, and FileReader specs to get a sense on how this pattern works.


From: Mandyam, Giridhar [mailto:mandyam@quicinc.com]
Sent: Thursday, December 20, 2012 10:23 AM
To: Jim Barnett; public-media-capture@w3.org
Subject: RE: new draft of recording proposal

I had sent out recommended changes to the spec earlier this week, and it looks like several items that I suggested are not in this current version.  How do we resolve merging your most recent changes with what I had suggested?

From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
Sent: Thursday, December 20, 2012 10:15 AM
To: public-media-capture@w3.org<mailto:public-media-capture@w3.org>
Subject: new draft of recording proposal

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