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

Re: [WebSQLDatabase] Adding a vacuum() call

From: Charles McCathieNevile <chaals@opera.com>
Date: Sat, 13 Mar 2010 05:09:52 +0100
To: "Jeremy Orlow" <jorlow@google.com>, "Dirk Pranke" <dpranke@chromium.org>
Cc: "Dumitru Daniliuc" <dumi@google.com>, João Eiras <joaoe@opera.com>, public-webapps <public-webapps@w3.org>
Message-ID: <op.u9hm6qixwxe0ny@widsith.local>
On Fri, 12 Mar 2010 22:31:15 +0100, Dirk Pranke <dpranke@chromium.org>  
wrote:

> 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.

cheers

Chaals

> -- Dirk
>
> 2010/3/9 Jeremy Orlow <jorlow@google.com>:
>> On Mon, Mar 8, 2010 at 8:47 PM, Dumitru Daniliuc <dumi@google.com>  
>> wrote:
>>>
>>>
>>> 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.
>>
>> 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
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Saturday, 13 March 2010 04:10:38 GMT

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