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

On Jul 25, 2009, at 1:18 PM, Aaron Boodman wrote:

> On Fri, Jul 24, 2009 at 6:51 PM, Nikunj R. Mehta<nikunj.mehta@oracle.com 
> > wrote:
>> It appears that Database, SQLTransactionCallback,
>> SQLTransactionErrorCallback, SQLVoidCallback, SQLTransaction,
>> SQLStatementCallback, and SQLStatementErrorCallback interfaces can  
>> all be
>> eliminated from WebDatabase completely.
>>
>> Given WebWorkers and DatabaseSync, why do we need the Database  
>> object at
>> all? Are there use cases that cannot be satisfied by the  
>> combination of the
>> two that?
>
> All use cases are implementable with workers + synchronous databases
> given enough effort.

This is really good to know. This likely means that the WG would be  
required to find strong reasons to keep the duplication.

> But using workers is a large burden: they are
> completely separate JavaScript environments that share nothing with
> the main web page. Having to use that for simpler use cases would be
> very unfortunate.

I am not sure how large a burden this is. Can you quantify it? Can you  
explain why this would be unacceptable?

>
> If all we had was synchronous databases and you could only use them
> from workers, I think you'd immediately start seeing developers create
> JavaScript wrappers that look a lot like our current Database
> interface, because...

If there is a good chance for a JavaScript library to thrive in this  
environment, then there is all the more reason for the WG to not bake  
in a required browser interface.

>
>> There is a brand new programming model being promoted by the Database
>> object, it is as complex as it gets and seriously I cannot get it.
>
> The current Database interface falls naturally out of the  
> requirements:
>
> a. No IO on the UI thread
> b. Don't allow developers to forget to close transactions
> c. Support using databases from the JavaScript on web pages (don't
> require workers)
>
> If you can think of an alternate interface that meets these
> requirements, I'd love to hear it. But I suspect it will look very
> much like what we have.

The programming model espoused by WebDatabase's async portion is that:

1. the programmer does all the SQL work in one or more asynchronous  
callbacks.
2. callbacks are always linear, however, the program performs its own  
stack management to keep the requisite context around for doing its  
processing inside asynchronous callbacks. If multiple calls to the  
database are required to perform certain work, then the programs  
become a chain of nested callbacks.
3. the only supported model of transaction isolation is serialization  
of all database access.

This is certainly foreign to most database developers. Editors and/or  
others share the burden of proof that there is no alternative to this  
and that there is merit in standardizing a brand new programming model.

>
> Also, the programming model is not that novel. It is a straightforward
> application of IOC to ensure that transactions are always closed.
>

Aaron misunderstands me here as I have no objection, per se, to IOC or  
RAII. The problem is with the rest of the programming model which he  
has not yet justified as having merit.

Nikunj
http://o-micron.blogspot.com

Received on Monday, 27 July 2009 18:58:14 UTC