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

On Wed, Aug 12, 2009 at 4:33 PM, Ian Hickson<ian@hixie.ch> wrote:
> 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.

My point was just that using a closure eliminates the case where a
transaction gets left open because of buggy code. It eliminates the
problem where a transaction should have been closed, but wasn't.

You're right that it does nothing for an infinite loop inside a
transaction. Nothing will save us from that.

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

Yes, that is what I was proposing.

- a

Received on Wednesday, 12 August 2009 23:55:13 UTC