RE: Comments on the revised recording proposal

Comments in-line

From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan
Sent: Monday, December 10, 2012 5:20 AM
To: Jim Barnett
Cc: public-media-capture@w3.org
Subject: Comments on the revised recording proposal

The type "Boolean" should be written as "boolean".

>> I’ll fix this.


I think the language around "once timeslice milliseconds of data have been gathered, the UA must raise a dataavailable event containing that Blob of recorded data" needs to be relaxed a bit to allow for the fact that UAs often can't map recorded data chunks to precise millisecond boundaries.

>> How would you suggest rephrasing this?  As I read it, the current language doesn’t require that _exactly_ timeslice milliseconds of data be in the event, only that _at least_ timeslice milliseconds of data be available.  Do we want to add a phrase saying that the UA may wait until it finds a convenient data boundary?  I’m just not sure how to say it.


"When this method is called, if recording is true, the UA must raise a dataavailable event containing its current Blob of data and then start collecting a new Blob." Is this event fired synchronously during the requestData(), or asynchronously? I suggest the latter. The spec should use the HTML terminology "queuing a task" (and specify the task source).

>> This would be asynch.  I’ll update the spec.


"A recordingwarning event will be raised if this is called while recording is occurring, and the call will have no effect." For a programmer error like this Web platform APIs don't usually raise an event. UA-specific developer tools can and should alert Web developers, and there is no need to address this in specs.

>> Is it really accepted practice to silently ignore a command?  That’s what Travis had in his original proposal, but I thought it was better practice to signal the problem.  However if it’s standard API design to ignore this kind of error, I’ll change the spec.


As others mentioned, the event objects need to be specified in more detail.

Instead of introducing an "auto" format, just make the fields of the Formats dictionary optional.

What are the semantics of calling setRecordingOptions and passing a list of formats for 'container', 'audio' or 'video'? This needs to be explained. It might make more sense to avoid using "Formats" for both getting and setting format options. In fact, why aren't we just using a single MIME type to specify the format to record into, since a MIME type can specify both the container and codec types? Could we just have a "DOMString? attribute type" (for consistency with Blob), plus a method "boolean canRecordType(type)"? (I suggested this before, but I guess it was rejected --- which is fine except I can't find the reason :-).)

>>  Do others have an opinion on this?  Are there sufficient MIME types declared to cover every combination of container and codec that an app might want to use?


Rob
--
Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28]