[whatwg] Storage quota introspection and modification

[Ian Fette (イアンフェッティ)]

Am 11. März 2010 14:35 schrieb Mike Shaver <mike.shaver at gmail.com>:

> 2010/3/11 Ian Fette (イアンフェッティ) <ifette at google.com>:
> > AFAIK most browsers are setting a default quota for storage options that
> is
> > on the order of megabytes.
>
> Could well be, indeed.  It sounded like you'd done some thinking about
> the size, and I was curious about how you came up with that number
> (versus some %age of available disk, for example).
>
>
To be honest, I don't think it was all that scientific. More like "If
someone discovered that random.com was storing 1GB of stuff on their disk
and they didn't know, would they (rationally or not) get pissed off about
it?" and that seemed to be a yes. 5Mb? no. We could go for a percentage of
the disk, but again, how much to take? If someone discovers that their disk
is half full, are they going to think to open up their browser to clear
stuff out? Do they even know where their browser's profile directory is? Or
are they just going to get frustrated and curse.


> > Yes, but I think there may be uses of things like storage for non-offline
> > uses (pre-fetching email attachments, saving an email that is in a draft
> > state etc.)  If it's relatively harmless, like 1mb usage, I don't want to
> > pop up an infobar, I just want to allow it. So, I don't really want to
> have
> > an infobar each time a site uses one of these features for the first
> time,
> > I'd like to allow innocuous use if possible
>
> I think of an infobar as relatively innocuous, and a good balance of
> user awareness versus flow interruption, but I repeat my lack of
> interaction design credentials!
>
>
But I really don't want to see infobars everywhere :)


> (Your attachment example is an interesting one, I think: do I get the
> request if I request too-big an attachment, but not if it's a small
> one?  Or if it's saving a blog post draft that has a bunch of images
> in it, vs. one that's 140 chars long.)
>

exactly


>
> > But at the same time, I want
> > apps to be able to say up front, at a time when the user is thinking
> about
> > it (because they just clicked something on the site, presumably) "here's
> > what I am going to need".
>
> OK, I see.  What if we had the named-subquota stuff, and the way you
> triggered that request was creation of a named subquota?  That would
> also encourage app developers to provide a description of the quota,
> and perhaps the sort of "necessary for offline operation" vs "improves
> performance" vs "supports additional features".  The named subquota
> creation request could give an initial requested size and estimated
> upper bound for the size.  An async event delivered back (or a
> callback called) could tell the app what quota it was granted, if any
> (or maybe just that it was granted some, but the size limit wasn't
> specified).
>
>
My initial reaction was that I don't know how much I buy into the "subquota"
part (vs named quota in general). E.g. if we can't enforce any of the
subquota distinctions beyond a same-origin level, it seems of limited use.
Upon further thought though, if you assume apps you trust are well behaved,
then this may actually be a good idea. Would make displaying this
information to users easier as well, even if relatively few users ever do go
into options UI.

At this point, if named subquota would meet the requirements I initially put
forth (request a set of resource quotas that I think I need, and get a
callback if I get them), and ideally be able to interrogate some sort of
information about the named subquota (be it "how many bytes are free" vs
"what are you reasonably sure I can store" I really don't care), I am all
for it ;-)

Is there some "named subquota" thread that I need to +1?


> Mike
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100315/a5659b47/attachment-0002.htm>