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

Re: [WebSQLDatabase] Adding a vacuum() call

From: Dumitru Daniliuc <dumi@google.com>
Date: Mon, 8 Mar 2010 12:47:18 -0800
Message-ID: <e753f47f1003081247g2ca59b4am9f53abbc37d8d255@mail.gmail.com>
To: Joćo Eiras <joaoe@opera.com>
Cc: public-webapps <public-webapps@w3.org>
On Mon, Mar 8, 2010 at 3:39 AM, Joćo Eiras <joaoe@opera.com> wrote:

>  I don't see how the callbacks are useful though. Vacuum works
>>> transparently, its effects are not visible, and what should the page do
>>> in
>>> case of error ?
>> i was thinking of something like:
>> db.defragment(errorCallback, successCallback);
>> showAPrettyImageAndAskTheUserToWait();
>> function errorCallback(error) {}
>> function successCallback() {
>>  getRidOfThePrettyImageAndRestartTheApp();
>> }
>> just like you, i'm not sure if the error callback is useful at all, but i
>> thought i'd add it to make the defragment() call look more like a
>> transaction. maybe we don't need it.
> True, but this is a kind of operation that could very well just run on the
> background, with a single optional callback when it's done (the webpage
> can't do anything if an error is detected anyway).

ok, so let's drop the errorCallback: vacuum([optional] successCallback);

> The user agent would need to queue any subsequent transactions if a vacuum
> is running. I would consider it as an hint, and after all webpages that own
> references to the underlying data files are closed, would do a vacuum. So,
> if you have many tabs on gmail, and that a single gmail instance tries to do
> multiple vacuums, it would equiv to one single vacuum operation.

what do we do if some databases are opened for the entire life of the
browser? for example, i open my browser which has myfavoriteapp.com set as
its homepage. myfavoriteapp.com immediately opens a DB, and i only close
that app when i close the browser. when would the browser vacuum
myfavoriteapp's DBs in this case?

i think it's ok for the UA to vacuum some DBs automatically when it thinks
it's a good time to do so; however, if a platform supports the vacuum/defrag
call (i.e. if it doesn't treat it is a no-op), then i think a vacuum call
coming from the app should be immediately scheduled (yes, the subsequent
transactions would have to wait for the vacuuming to finish running). in
some cases, the apps know better than the UA when to vacuum their DBs.

by the way, we should probably agree on a name for this call. which one do
you prefer? vacuum, defragment, defrag, something else? i don't have a
strong opinion.

Received on Monday, 8 March 2010 20:47:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:05 UTC