Re: [WebSQLDatabase] Adding a vacuum() call

On Fri, 12 Mar 2010 22:31:15 +0100, Dirk Pranke <>  

> I admit to not being super familiar with the spec as it currently
> stands, but I find the idea that we would add something like this
> fairly unappealing. I'm not familiar with any other database API
> that asks the application programmer to some sort of GC as part of
> the application. I almost feel like if you're going to add this,
> you should drop any pretense of calling this a generic SQL
> interface, and just call it the "WebSQLLite spec".

It isn't a generic SQL spec, it is already a "WebSQLite" spec.

But I'm still not sure what the rationale is for this functionality. In  
particular, because the sense I got from the TPAC meeting was that nobody  
except Apple is especially keen on this spec as a long-term solution. So  
working on such low-level functionality doesn't seem very worthwhile -  
although if people are seriously going to implement it then knowing that  
will at least allow ongoing interoperability for those who choose to  
implement it.



> -- Dirk
> 2010/3/9 Jeremy Orlow <>:
>> On Mon, Mar 8, 2010 at 8:47 PM, Dumitru Daniliuc <>  
>> wrote:
>>> On Mon, Mar 8, 2010 at 3:39 AM, João Eiras <> 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  
>>> set as
>>> its homepage. 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.
>> I think vacuum is fine since the spec is already tied to the SQLite SQL
>> dialect.
>> collectGarbage() is another possibility
>> Go with whatever you think is most clear and accurate though.
>> J

Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk       Try Opera:

Received on Saturday, 13 March 2010 04:10:38 UTC