Re: Updating Quota API: Promise, Events and some more

On Sat, Aug 17, 2013 at 3:01 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Fri, Aug 16, 2013 at 6:56 AM, Kinuko Yasuda <kinuko@chromium.org>
> wrote:
>
> I had a few bike-sheddy comments as well.
>
> > Now the new draft looks like:
> >
> >  enum StorageType { "temporary", "persistent" };
> >
> >   partial interface Navigator {
> >     readonly attribute StorageQuota storageQuota;
> >   };
> >
> >   [NoInterfaceObject] interface StorageInfo {
> >     unsigned long long usageInBytes;
> >     unsigned long long quotaInBytes;
> >   };
>
> I think these can be simplified to simply 'usage' and 'quota'. The
> fact that it's in bytes doesn't really need to be spelled out in the
> property name I think. Feedback that we've gotten from authors is that
> they prefer short names.


Ok, I don't have strong opinion on the names. Some developers
seem to prefer clearer names but I think just 'usage' and 'quota'
would work in this case.


> >   [NoInterfaceObject] interface StorageQuota {
> >     readonly attribute StorageType[] supportedTypes;
> >
> >     // Queries the current storage info.
> >     Promise<StorageInfo> queryStorageInfo(StorageType type);
>
> I think simply 'getInfo' might be enough here. It should already be
> obvious that it's storage-quota related.


Sounds good. Actually I wondered the same.


>  >     // Requests a new quota for persistent storage.
> >     Promise<StorageInfo> requestPersistentQuota(unsigned long long
> > newQuotaInBytes);
> >
> >     // Creates a new StorageWatcher object to watch the storage changes.
> >     StorageWatcher createStorageWatcher(StorageType type)
>
> This could probably simply be done using a constructor. I.e.
>
> new StorageWatcher("persistent");


Yup... I once wondered we may not want to expose more
constructors on global namespace, but constructor way
actually makes it simpler.

>   [NoInterfaceObject] interface createStorageWatcher {
> >     // Fired when when the remaining storage space becomes lower
> >     // than 10% of all available space for the type, or before the quota
> > backend
> >     // triggers eviction (for temporary case), whichever happens first.
> >     attribute EventHandler onstoragelow;
> >   };
>
> Actually, the other two events made sense to me. Without onstorageok
> the page has to poll queryStorageInfo to know when it's "out of the
> woods".
>
> Actually, *only* having onstoragechange would solve both the use case
> of detecting when you are running low on storage, as well as when you
> are "out of the woods". Especially if we provide both the quota and
> the amount of used space in the event.


Right.  I think probably we should add either "a combination of
storagelow + storageok" or "storagechange", and the latter would be
more complete (and possibly be simpler).

One concern for adding storagechange event is how frequently
the event is going to be fired.  In the former email I tentatively wrote
this to be fired every 1 second at most frequent (or whenever the
storage info is changed), but this may be still too frequent if many
apps are contending to a storage space.  Do you have any opinion
or preference on this?



> / Jonas
>

Received on Monday, 19 August 2013 16:33:31 UTC