On Mon, Mar 8, 2010 at 8:47 PM, Dumitru Daniliuc <d...@google.com> wrote:
> > > On Mon, Mar 8, 2010 at 3:39 AM, João Eiras <jo...@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