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

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

From: Aaron Boodman <aa@google.com>
Date: Sat, 25 Jul 2009 13:18:03 -0700
Message-ID: <278fd46c0907251318i21cd6819qffff7bd2f76489b5@mail.gmail.com>
To: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
Cc: public-webapps WG <public-webapps@w3.org>
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. 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.

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

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

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

- a
Received on Saturday, 25 July 2009 20:18:42 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC