Re: Communicating memory pressure in mediastream recording

On Tue, Aug 13, 2013 at 6:40 AM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> On 2013-07-31 06:58, Robert O'Callahan wrote:
> > On Wed, Jul 31, 2013 at 4:53 PM, Martin Thomson
> > <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
> >
> >     On 31 July 2013 06:47, Robert O'Callahan <robert@ocallahan.org
> >     <mailto:robert@ocallahan.org>> wrote:
> >      >> Is there an API surface that might support this already?  Or
> would
> >      >> this require that things just sort of stop working in the
> interim?
> >      >
> >      > I'm not sure what you mean.
> >
> >     Is there some existing way that a browser might communicate to an app
> >     that there is memory/resource pressure, in such a way that an app
> >     might infer the reasons for errors that might arise in that state?
> >
> >
> > No.
>
> What exists (as a document, I don't know about implementation status) is
> the Quota API. With it you could at least check how much memory that is
> available, and also request storage.
>
> https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html
>
>
I think we need to clarify the storage relationship between screen
recording to make use of Quota. Do recording artifacts consume temporary
storage? Permanent storage?

This is one advantage of the tighter integration with the File API which
Rachel and I proposed: it is much more clear which storage quota is being
used during recording.

I think that quota polling is an undesirable way for an app to detect
storage pressure for an ongoing process such as this. Ordinarily the app is
in control of writes into its quota, so quota exhaustion events are not
very useful. If there are background processes like this which are using
quota, perhaps the app needs such events, but I think it would be more
natural to use the built-in flow control mechanisms in Stream.



> > Rob
> > --
> > Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny
> > eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha
> > iids  teoa stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e
> > tfaokreg iyvoeunr, 'm aotr  atnod sgaoy ,h o'mGee.t"  uTph eann dt hwea
> > lmka'n?  gBoutt  uIp  waanndt  wyeonut  thoo mken.o w *
> > *
>
>