RE: Communicating memory pressure in mediastream recording

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