Re: [WebSQLDatabase] Adding a vacuum() call

joao,

if i understand correctly, you basically want to have an automated system
implemented in the browser that decides when to vacuum databases (or at
least make sure it doesn't happen too often). and the vacuum() calls would
be just one of the parameters that the system takes into account. i think
having such a system is fine, but doesn't need to be spec'ed. at the same
time, i think it's worth having a spec'ed vacuum() call that gives the app
some guarantees. in particular, i would like the completionCallback to be a
signal that the database is in a good shape and ready for more work. so how
about this:


   1. if the UA doesn't support the vacuum() call, go to step 3.
   2. queue up a task to vacuum the database. if the UA decides that
   vacuuming is not needed at this time, the vacuuming task scheduled in this
   step could be a no-op.
   3. when the vacuuming task completes, queue up a task to invoke the
   completion callback, if one was specified.

i think this spec should allow you to treat the vacuum() call as a hint,
while also guaranteeing that:
1. the UA believes the database is in a good shape when the completion
callback is called.
2. the completion callback is called as soon as UA believes the DB is in a
good shape.

what do you think?

thanks,
dumi


On Thu, Mar 11, 2010 at 4:13 PM, João Eiras <joaoe@opera.com> wrote:

> 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
>>
>>
>>