RE: Comments on the revised recording proposal

Robert,
   Your statement “For programmer errors that are detected synchronously, the two common patterns are to ignore the call, or throw an exception. “  seems to me to be a relevant topic for Thursday’s call, which lists “error handling” on the agenda.  I recall Anant saying that we wanted to limit the use of exceptions to things like syntactic errors (arguments of the wrong type, etc.)  You’re suggesting that, at least in some cases, it’s an option to simply ignore the API call.   Maybe we can decide on a policy for when to throw an exception and when to ignore.  I would think that the policy should be the same for webRTC and MediaCapture.

For task source, we now have two votes for the DOM manipulation task source.  Unless someone comes up with a cogent objection, that’s what I’ll use.

I’ll think about the wording for the size of the Blob.  Would it suffice to say “…once at least timeSlice milliseconds of data have been colleced, raise a dataavailable event containing the Blob of collected data.  The Blob _should_ contain as close to timeslice milliseconds of data as possible.”  This allows rounding up but not down.   Is rounding down desirable?  Allowing that would make the wording even squishier, as far as I can see.


-          Jim

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

On Tue, Dec 11, 2012 at 3:04 AM, Jim Barnett <Jim.Barnett@genesyslab.com<mailto:Jim.Barnett@genesyslab.com>> wrote:
From: rocallahan@gmail.com<mailto:rocallahan@gmail.com> [mailto:rocallahan@gmail.com<mailto:rocallahan@gmail.com>] On Behalf Of Robert O'Callahan

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.

Me neither. Perhaps we should say that the value is just a hint, and the UA should try to ensure there are about 'timeslice' milliseconds of data represented by each data packet, but there are no normative requirements.
"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.

For programmer errors that are detected synchronously, the two common patterns are to ignore the call, or throw an exception. I think either would be fine here.
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?

I suggest the DOM manipulation task source, since that's what the media element events 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]