On Fri, 12 Mar 2010 22:31:15 +0100, Dirk Pranke <dpra...@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 <jor...@google.com>:
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
--
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
