RE: revised recording proposal

My recommended changes  on the latest recording proposal (in bold/italics).  Summary:


a)      Added pause()/resume() methods with appropriate event handlers and status flag.  There may be a cleaner way to implement this functionality without adding two new methods, however.  One approach I thought of was changing the definition of stop recording to cover a pause action, and adding a new method called endRecording() to finalize a recording of a stream.

b)      Added the ability to return data upon a recording error.  In my proposed changes, this is a separate event from a normal recording error.  However there could be a single error event with an optionally returned data in the form of a blob.

c)       Added recommended error codes, with the Geoloc API as the inspiration.  How much or how little fingerprinting surface we want out of the error object should be discussed further.

d)      Modified recording formats to reflect selection of video dimensions.

Some things I did not do:


i.                     Have not suggested warning codes.  It does not look like there is agreement within the group as to whether it makes sense to raise warning events.

ii.                   Added JS examples.  I will be happy to suggest some code examples when there is firmer agreement on the spec.

Look forward to any follow up from you all (questions, corrections, suggested modifications, etc.).

-Giri Mandyam, Qualcomm Innovation Center

From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
Sent: Friday, November 30, 2012 7:13 AM
To: public-media-capture@w3.org
Subject: revised recording proposal

Here's an updated proposal, which I have checked into mercurial at http://dvcs.w3.org/hg/dap/file/802e29e48f73/media-stream-capture/RecordingProposal.html


-          Jim