Re: [WebSQLDatabase] Adding a vacuum() call

On Fri, 12 Mar 2010 01:08:41 +0100, Dumitru Daniliuc <dumi@chromium.org>  
wrote:

> joao,
>
> it looks like we mostly agree on this feature, so i was wondering if we
> could formally agree on a spec. here's what i propose:
>
> 1. name: vacuum. to the best of my knowledge, all current WebSQLDatabases
> implementations use SQLite, and in SQLite the command is called VACUUM.  
> so
> it seems to me that we might as well call the new function vacuum().  
> what do
> you think?

I'm fine with it but...

>
> 2. spec: no need for an error callback.
>
> interface Database {
>   // the methods and properties currently in the spec
>   void vacuum(in optional SQLVoidCallback successCallback);
> };
>
> 3. what the call should do: the purpose of this call is to allow apps to
> vacuum/compact/defragment/clean up their databases whenever they see  
> fit. a
> call to vacuum() could take a considerable amount of time (especially on
> larger or highly fragmented databases); therefore, it is not recommended  
> for
> web apps to call this method during periods of high activity.
>
> how to process a vacuum() call:
>
>    1. if the UA does not support this call (mobile browsers?), jump to  
> step
>    3.
>    2. queue up a task to vacuum/compact/defragment/clean up the database.
>    3. if the task succeeds, and a success callback is provided, queue up  
> a
>    task to invoke the success callback; in all other cases (the task  
> failed, or
>    no success callback was provided), do nothing: proceed to the next  
> task in
>    the queue.
>
> does this seem acceptable? we (google engineers interested in this) feel
> that UAs should either not implement the vacuum() call, or they should
> respect it (rather than taking it as a hint). it is ok for UAs to keep  
> track
> of things like system idleness or databases closing to do more vacuuming
> that the apps asked for, if they want to. however, we feel that a  
> vacuum()
> request by an app should not be postponed, simply because sometimes apps
> know better than UAs when the best time to vacuum is (it might be nice to
> give apps more information on how fragmented their databases are, but  
> that's
> a separate discussion).
>

I unfortunately don't agree with this last sentence :) Web pages do not  
have a way to know the level of fragmentation, and the last thing user  
wants is a web page calling vacuum() before each transaction, *just to be  
safe*, because of potential fragmentation.

But the API is good I think.

> thanks,
> dumi
>
>

Received on Friday, 12 March 2010 00:14:17 UTC