RE: Communicating memory pressure in mediastream recording

Greg,
Yes.  And when the issue of warning events came up before, there were objections to the introduction of an extra class without good motivation.   So warning events are currently in limbo.


-          Jim

From: Greg Billock [mailto:gbillock@google.com]
Sent: Monday, July 29, 2013 5:42 PM
To: Jim Barnett
Cc: public-media-capture@w3.org
Subject: 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<mailto: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<mailto:gbillock@google.com>]
Sent: Monday, July 29, 2013 12:34 PM
To: public-media-capture@w3.org<mailto: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