On Fri, 12 Mar 2010 01:08:41 +0100, Dumitru Daniliuc <[email protected]>
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
