- From: João Eiras <joaoe@opera.com>
- Date: Fri, 12 Mar 2010 01:13:36 +0100
- To: "Dumitru Daniliuc" <dumi@chromium.org>, "Jeremy Orlow" <jorlow@google.com>
- Cc: public-webapps <public-webapps@w3.org>
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