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