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

On Mon, Jul 27, 2009 at 11:55 AM, Nikunj R.
Mehta<nikunj.mehta@oracle.com> wrote:
>
> 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?

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
interface:

http://code.google.com/p/html-5-sql-player

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

Yes, this is the model.

Note that you only need to chain callbacks if you need to do
javascript work after them. If you just need to do a bunch of
statements, you can fire-and-forget and they will be queued. Or you
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.

I can't speak to what "most database developers" will find foreign.
Even though you work at a database company, I think it is hard for
anyone to make generalization about what "most" of anyone will think
about anything.

What I can say is that given the requirements, this is the only
interface I can imagine that works. I can also note that as a web
developer, I didn't find this interface foreign. It is a bit
unfortunate in the callbackyness, but I think it is a good tradeoff to
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
>> 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.

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