Re: Comments on the revised recording proposal

On Tue, Dec 11, 2012 at 3:04 AM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

>  *From:* 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]