Re: [WebSQLDatabase] Adding a vacuum() call

Instead of calling back on success only, maybe call back on completion
regardless of success or failure. This way the caller would know when the
potentially lengthy operation was done, regardless of the outcome.

2010/3/11 Dumitru Daniliuc <dumi@chromium.org>

> joao,
>
> it looks like we mostly agree on this feature, so i was wondering if we
> could formally agree on a spec. here's what i propose:
>
> 1. name: vacuum. to the best of my knowledge, all current WebSQLDatabases
> implementations use SQLite, and in SQLite the command is called VACUUM. so
> it seems to me that we might as well call the new function vacuum(). what do
> you think?
>
> 2. spec: no need for an error callback.
>
>
> interface Database {
>   // the methods and properties currently in the spec
>   void vacuum(in optional SQLVoidCallback successCallback);
> };
>
> 3. what the call should do: the purpose of this call is to allow apps to
> vacuum/compact/defragment/clean up their databases whenever they see fit. a
> call to vacuum() could take a considerable amount of time (especially on
> larger or highly fragmented databases); therefore, it is not recommended for
> web apps to call this method during periods of high activity.
>
> how to process a vacuum() call:
>
>    1. if the UA does not support this call (mobile browsers?), jump to
>    step 3.
>    2. queue up a task to vacuum/compact/defragment/clean up the database.
>    3. if the task succeeds, and a success callback is provided, queue up a
>    task to invoke the success callback; in all other cases (the task failed, or
>    no success callback was provided), do nothing: proceed to the next task in
>    the queue.
>
> does this seem acceptable? we (google engineers interested in this) feel
> that UAs should either not implement the vacuum() call, or they should
> respect it (rather than taking it as a hint). it is ok for UAs to keep track
> of things like system idleness or databases closing to do more vacuuming
> that the apps asked for, if they want to. however, we feel that a vacuum()
> request by an app should not be postponed, simply because sometimes apps
> know better than UAs when the best time to vacuum is (it might be nice to
> give apps more information on how fragmented their databases are, but that's
> a separate discussion).
>
> thanks,
> dumi
>
>
> 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
>>
>
>