W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [WebDatabase] Database interface (vs. DatabaseSync interface)

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 12 Aug 2009 23:33:48 +0000 (UTC)
To: Aaron Boodman <aa@google.com>
Cc: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>, Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, public-webapps WG <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.62.0908122329210.6420@hixie.dreamhostps.com>
On Mon, 3 Aug 2009, Aaron Boodman wrote:
> >
> > The API was intentionally made more obviously synchronous to avoid 
> > having to make people use callbacks.
> >
> > Would making all transactions automatically rollback if not committed 
> > when the event loop spins be an acceptable substitute solution?
> 
> A few problems with this:
> 
> - In the case of workers, it could be more common for a single event 
> loop entry to last a very long time. So closing the transaction on event 
> loop exit could effectively mean "never".

I don't think reentrant callbacks really get around that much, though 
maybe they make it a little more obvious.


> - It is likely to lead to difficult to debug issues. In the common path, 
> developers will close transactions because they will notice incorrect 
> code during development. It is only in the error cases that they will 
> forget to close the transactions. So every so often, you'll get errors 
> or hung workers (depending on what the behavior is spec'd to be when you 
> open a sync transaction while another is open in the same worker), and 
> no good way to track down the transaction that was left open. In my 
> experience with Gears, to avoid these issues, the very first thing 
> developers did was write a wrapper around the Gears API that worked the 
> way I'm suggesting.

Fair enough.


> I also don't see what not having a callback buys. I'm not sure if you 
> noticed, but I was suggesting that the callback be reentrant. So if you 
> do this:
> 
> var theResult = null;
> database.syncTransaction(function(tx) {
>   theResult = tx.executeSQL("select * from ...").rows[0].val;
> });
> alert(theResult);
> 
> It will do the right thing. Are you concerned that developers won't 
> realize that the callback is reentrant and will invest more effort 
> writing their code in an asynchronous style?

The only reason for not using callbacks in the sync API was that callbacks 
are harder to work with than the straight-forward imperative style.

I can change the spec to a hybrid style with statements in the imperative 
form but the transactions themselves using closures. Would that be ok?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 12 August 2009 23:34:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT