[whatwg] Asynchronous database API feedback

On Dec 10, 2007 4:04 PM, Dan Mosedale <dmose at mozilla.org> wrote:
> On Dec 10, 2007, at 12:21 PM, Geoffrey Garen wrote:
>
> >>> I'd hate for GMail to mysteriously stop working every couple of
> >>> days just because of some background process that I had no
> >>> knowledge of. As a developer, how would you debug such a problem?
> >>> As a tech support worker, how would you explain it to an end user?
>
> +1.  Having a bug in a single web-app be able to completely freeze the
> entire UI of the entire browser (not just that window/tab) seems like
> a pretty painful user experience, almost to the point of being
> unacceptable.  If an end user ran into this problem very often, I
> would expect them to blame the browser, and perhaps even switch to a
> browser which didn't have this problem (i.e. didn't support
> localStorage).

How does the globalStorage implementation deal with this problem? It
has a synchronous storage API. True it is probably designed for
smaller amounts of data, but there's nothing preventing an author from
using it for large amounts (is there?). Also, some of the concerns
raised here have nothing to do with the amount of data stored. Or does
globalStorage not guarantee that data is written when the setter
returns?

> As a user, assuming a synchronous interface with timeouts, I would
> almost certainly want my browser to enforce a _much_ shorter timeout
> than 5 seconds... something on the order of 200ms, maybe.  Anything
> that makes repainting stop just feels really bad.
>
> >> If we cannot provide this, I feel that localstorage will not be
> >> successful, so it won't matter what API it uses.
> >
> > I think this is a pretty extreme conclusion.
>
> I tend to agree.  Aaron, can you describe the thinking behind this
> conclusion in more detail?

It's just from attempting to use the API. It is pretty difficult. If
you imagine some code that does synchronization of mail, it is going
to be downloading items in batches. A simple schema might include
messages, threads, and contacts. With a synchronous API, you just
process these in a loop. Very straightforward.

With an asynchronous API, it gets quite a bit messier. Here's an
example of what it might look like:

var messages = incoming_data;

db.transaction(function(tx) {
  processNextMessage(tx);
});

function processNextMessage(tx) {

  if (!messages.length) return;

  tx.executeSql("insert into messages (id, subject, body) values (?, ?, ?)", [
}

Received on Tuesday, 11 December 2007 11:22:43 UTC