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