Re: Communicating memory pressure in mediastream recording

We'll probably have more useful to say about error states as we start the
implementation, but there is an onwarning event handler in the spec. That
may be a better match for messages like this, but my inclination would be
to include it in the error channel -- if it's something the app can respond
to, it's more of an emergency.


On Mon, Jul 29, 2013 at 9:58 AM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

>  Greg,****
>
> I’ve thought for a while that Low_memory would be more useful than
> out_of_memory.  A “you’re totally hosed, dude” message is really not as
> useful as “you’re gonna be hosed if you don’t do something soon”.   One
> question is whether Low_Memory should be an error event or if we need a
> separate class of warning events  (and, if so, what are the other warnings?)
> ****
>
> ** **
>
> **-          **Jim****
>
> ** **
>
> *From:* Greg Billock [mailto:gbillock@google.com]
> *Sent:* Monday, July 29, 2013 12:34 PM
> *To:* public-media-capture@w3.org
> *Subject:* Communicating memory pressure in mediastream recording****
>
> ** **
>
> Another implementation issue that may be useful to surface in the API:****
>
> ** **
>
> In the record(timeslice) case, the implementation will probably not want
> to incur the latency penalty of writing each intermediate block to disk
> before creating the blob handle. This means some coordination is required
> to make sure the app doesn't let too much in-memory content accumulate.
> (The no-timeslice overload shouldn't have this weakness.)****
>
> ** **
>
> There's already a channel for communicating this kind of pressure with the
> onerror/onwarning event handlers. The ondataavailable event is the trigger
> for it, and there's already an OUT_OF_MEMORY error that can be used for
> failure if the implementation has to start dropping slices or take some
> other remedy. Should there be a LOW_MEMORY warning enum value to indicate
> to the app that if it's waiting around to delete intermediate memory it
> should do so immediately?****
>
> ** **
>
> To reinforce this coordination, would it be helpful to have
> record(timeslice) also take an onerror handler to help make sure app
> developers are accounting for the increased coordination effort they'll
> need to have to use the API successfully?****
>
> ** **
>
> -Greg****
>
> ** **
>
> ** **
>