Re: [WARP] comment on subdomains
Le jeudi 04 mars 2010 à 17:03 +0100, Robin Berjon a écrit : Good suggestion, the latest ED reflects the above change plus another reference where subdomains are defined. Please let us know if that works for you! It does, thanks! Dom
Re: [WebSQLDatabase] Adding a vacuum() call
On Fri, Mar 5, 2010 at 2:32 AM, João Eiras jo...@opera.com wrote: On Fri, 05 Mar 2010 03:22:00 +0100, Dumitru Daniliuc d...@chromium.org wrote: Hi, We (Chromium) would like to add a vacuum() call on the Database object. [...] I would argue about having something a bit more generic for naming like defragment(). 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 ? Given that an operation like vacuum would be disk IO intensive, would it be good to give the webpage control over a feature that can have significant performance concerns ? I'm sure a UA could always ignore it and/or vacuum whenever it wants...but the drawback is that if you start vacuuming and then the app tries to open the database, you might get some serious jank in the web app. While computers benefit from good file IO performance, that's not quite true in many mobile devices. So, the API would be more like an hint ? How can the webpage know the level of fragmentation of the data file ? Sqlite supports incremental vacuum http://www.sqlite.org/pragma.html so this kind of feature should be left for sqlite to handle for itself. From that page: Note, however, that auto-vacuum only truncates the freelist pages from the file. Auto-vacuum does not defragment the database nor repack individual database pages the way that the VACUUM lang_vacuum.html command does. In fact, because it moves pages around within the file, auto-vacuum can actually make fragmentation worse.
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
On Thu, Mar 4, 2010 at 7:44 PM, Nikunj Mehta nik...@o-micron.com wrote: On Mar 4, 2010, at 10:55 AM, Kris Zyp wrote: On 3/4/2010 11:46 AM, Nikunj Mehta wrote: On Mar 4, 2010, at 10:23 AM, Kris Zyp wrote: On 3/4/2010 11:08 AM, Aaron Boodman wrote: [snip] * There is nothing preventing JS authors from implementing a promise-style API on top of IndexedDB, if that is what they want to do. Yes, you can always make an API harder to use so that JS authors have more they can do with it ;). You will agree that we don't want to wait for one style of promises to win out over others before IndexedDB can be made available to programmers. Till the soil and let a thousand flowers bloom. The IndexedDB spec isn't and can't just sit back and not define the asynchronous interface. Like it or not, IndexedDB has defined a promise-like entity with the |DBRequest| interface. Why is inventing a new (and somewhat ugly) flower better than designing based on the many flowers that have already bloomed? I meant to say that the IndexedDB spec should be updated to use a model that supports promises. If the current one is not adequate then, by all means, let's make it. However, we don't need a full-fledged promises in IndexedDB. I hope you agree this time. FWIW, I agree. To get promises to work with the current event based implementation, it'd be somewhat complex. Since there can only be one request in flight at a time, the implementation would need to know which requests would be using the same request object and implement a queue for each one (or implement a global queue if that's not practical). Whenever an onsuccess or onerror callback is called, it'd need to check to see if there are any queued up requests (and would fire them if so). This seems complex and ugly, but certainly possible. If the interface were callback based, a library would simply create a promise object, create an onsuccess closure, create an onerror closure, and pass those into the callbacks. When the callbacks are called, they'd have a reference to the promise (since they were created with access to the promise object due to their scope) and could easily fulfill the promise. Of course, I'm probably re-inventing the wheel here; there are enough other callback based APIs that I assume this is a solved (and optimized problem). Are there any other APIs that use the request event based style like how IndexedDB is currently specced? If so, can anyone share any experience with the list? If not, does anyone foresee major problems and/or have an opinion on how easy it'll be to adapt promises to the API? For what it's worth, regardless of the answers to the above questions, I think we should switch to a callback based model. It's great to use events when natural to do so, but this is a very unnatural use. It provides artificial limitations (only one request in flight at a time, per request object). It's ugly and confusing syntax wise (hard to keep track of which request object is associated with which request method, requires multiple statements to do each request, requires the handlers to be placed prior to the actual call...which is why the async example in http://www.w3.org/TR/IndexedDB/#introduction is so difficult to read, etc). And there really isn't any precedent (that I'm aware of) for using events like this. And the web developers I've spoken to have all been confused by the async API. I believe the API itself won't need to change much at all in order to make callbacks work. I'm happy to take a shot at making the necessary edits if no one objects to changing the async API to a callback based one. J
Re: [WebSQLDatabase] Adding a vacuum() call
hi joao,
thanks for your comments!
I would argue about having something a bit more generic for naming like
defragment().
that's totally fine with me.
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.
Given that an operation like vacuum would be disk IO intensive, would it be
good to give the webpage control over a feature that can have significant
performance concerns ?
first, i think it's better to give big, always-on apps access to a
potentially expensive clean-up call, than not give them any way at all to
defragment their databases. second, the app which called defragment() is the
only one that should notice the performance overhead (in practice, other web
apps might notice it too because of slower IO, but this is no different from
having an external, non-web app doing some intensive IO work and slowing
down all web apps). and third, most apps will probably never need to use
this call; it is mostly intended for apps with big databases that are always
open on a user's PC. those apps would usually know when they can call
defragment() without slowing down the user (for example, they could do it
when the app is idle).
While computers benefit from good file IO performance, that's not quite
true in many mobile devices. So, the API would be more like an hint ? How
can the webpage know the level of fragmentation of the data file ?
on mobile devices i'm imagining the quotas and DBs are pretty small, in
which case defragmenting databases probably wouldn't save much space anyway.
so maybe those platforms should decide that they never need to do any kind
of maintenance on their DBs and make defragment() a no-op?
i don't think a webapp can figure out the level of fragmentation (maybe we
need an API to expose some quota/DB size information to the webapp?).
however, it could use other criteria to decide when to call defragment():
once every couple of weeks, when the system is idle, etc.
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.
thanks,
dumi
