RE: Comments on the revised recording proposal

It's mostly a question of message priority. If you use a new task source, then your recording-related events can be pre-empted by [potentially] higher-priority messages in other queues. Prioritization of queues, however, is specifically not defined and left up to the UA. Personally, I don't think this needs a new queue. I'd use the DOM manipulation task source.

From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
Sent: Monday, December 10, 2012 7:07 AM
To: robert@ocallahan.org
Cc: public-media-capture@w3.org
Subject: RE: Comments on the revised recording proposal

One other question: what would the right task source for recording tasks be?   They might fit under the user interaction source, since the media itself is likely part of a user interaction,  but the user himself may have nothing to do with the recording.  On the other hand, recording isn’t important enough to need its own task source, is it?  So what should it be?


-          Jim

From: rocallahan@gmail.com<mailto: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<mailto:public-media-capture@w3.org>
Subject: Comments on the revised recording proposal

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

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.

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

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

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

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]