W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

[WebSQLDatabase] Adding a vacuum() call

From: Dumitru Daniliuc <dumi@chromium.org>
Date: Thu, 4 Mar 2010 18:22:00 -0800
Message-ID: <e753f47f1003041822p3e4c0657re9d1a8e83b11ce32@mail.gmail.com>
To: public-webapps <public-webapps@w3.org>
Hi,

We (Chromium) would like to add a vacuum() call on the Database object. The
idea is to allow the SQL engine to vacuum/compress/clean-up/do some
potentially expensive maintenance work on the respective database. In
SQLite's case, in particular, the vacuum() call would issue a VACUUM command
(which cannot run in a transaction, hence the web app developers do not have
access to it currently), which would make SQLite compact the database by
reusing the empty space on fragmented pages. We think this call is
necessary, because fragmented databases could lead to apps prematurely
reaching their quota limits.

Letting the UAs deal with this problem is not always an option. For example,
big apps like Gmail could always be "on" (loaded as soon as the browser
comes up and closed only when the browser shuts down), which means the UAs
would never have an opportunity to clean-up/compact the databases of those
apps without blocking them. In these cases, we believe the apps should be
responsible (and should have the opportunity) to clean up their own
databases when they feel that it is the best time to do so.

So we were wondering if it makes sense to add this call to the
WebSQLDatabases spec too.

The call would look like this:

interface Database {
  // the methods and properties currently in the spec
  void vacuum(in optional SQLVacuumErrorCallback errorCallback, in optional
SQLVoidCallback successCallback);
};

[Callback=FunctionOnly, NoInterfaceObject]
interface SQLVacuumErrorCallback {
  void handleEvent(in SQLError error);
};

And the steps would be the following:

   1. If vacuum() is called inside a transaction on the same database, jump
   to the "in case of error" steps below.
   2. Queue a task to vacuum, compress, clean-up or do any other necessary
   maintenance work on the given database.
   3. If the operation succeeds and a successCallback is provided, queue a
   task to invoke the successCallback.
   4. If the clean-up operation fails in any way, jump to the "in case of
   error" steps below.

In case of error:

   1. In an errorCallback is provided, queue a task to invoke the
   errorCallback.


Thanks,
Dumi
Received on Friday, 5 March 2010 02:22:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:37 GMT