


From: Aaron Boodman <aa@google.com>
Date: Mon, 27 Jul 2009 12:43:52 -0700
Message-ID: <278fd46c0907271243r234b9ddet2e56016659f0c2ed@mail.gmail.com>
Mehta<nikunj.mehta@oracle.com> wrote:
>> 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?

Well, Dimitri Glazkov wrote an emulation of HTML5 Database awhile ago
on top of Gears. This is a piece of what a developer would have to do
to emulate the async database interface on top of workers + a sync


It is about 3.5 kb, but all it does is emulate the async interface
inside a worker using a synchronous backend. A real emulation of HTML5
async databases on top of HTML5 sync databases would have to do this,
but move the async API out into the document context and put a
marshalling layer between the two parts, with tracking of open
transactions and statements on both sides.

So doing a real emulation would be quite a bit more complex. Let's say
you could do it in 7kb. For comparison, jquery compressed is 56k.
That's an increase of 12.5%. A lot.

I would guess that half of uses of the database API are simpler and
the async interface would address their needs. As one humble example,
my personal notepad site Gearpad (http://aaronboodman.com/gearpad)
uses Gears local storage and it would work just fine on top of the
async database interface. And the total code size of that site is 25
kb. It was designed specifically to be small and fast. Adding another
7kb for storage seems excessive.

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

It is a balancing act. Taking this approach is what has led to the
need for 56kb JavaScript libraries to do basic UI on the web. And even
though getElementsByTagName(), as one example, works fine, we have
gone and added getElementsBySelector(). Because it makes sense to
centralize commonly needed functionality in the browser rather than
have every app reimplement it.

>>> There is a brand new programming model being promoted by the Database
>> 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
>> require workers)
>> much like what we have.
> The programming model espoused by WebDatabase's async portion is that:
> 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.

Yes, this is the model.

can mix the two styles.

> 3. the only supported model of transaction isolation is serialization of all
> database access.

This seems orthogonal to the discussion we're having, right?

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

about anything.

be able to use databases without a worker.

This design also has the advantage of having implementations in webkit
and chromium so we at least know that it is implementable.


On the subject of the callbacks, you should note that only having the
sync API in workers won't fix this. The callbacks are a natural result
of the requirement to never leave transactions open.

The current sync proposal's explicit commit/rollback methods are a
bug, not a feature. They should be changed, so that the usage is along
the lines of:

database.syncTransaction(function(tx) {  // This callback is
re-entrant for JS point of view
  var result = database.executeSQL(statement, args);  // executeSQL is
synchronous rather than async inside sync transactions

So it would get rid of the statement callbacks, but not the transaction one.

>> Also, the programming model is not that novel. It is a straightforward
> 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.

The merit is in that it meets the requirements and no other model does.

- a
Received on Monday, 27 July 2009 19:44:33 UTC
