- From: João Eiras <joaoe@opera.com>
- Date: Mon, 08 Mar 2010 12:39:58 +0100
- To: public-webapps <public-webapps@w3.org>
>> 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). 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. >> Sqlite supports incremental vacuum http://www.sqlite.org/pragma.html so >> this kind of feature should be left for sqlite to handle for itself. >> > > in addition to what jeremy said, having auto-vacuum on is going to add > some > performance overhead to every transaction. this is not acceptable to some > apps. > I perused through the docs, and unfortunately auto-vaccum seems not like the ideal solution. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Received on Monday, 8 March 2010 11:40:37 UTC