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

On Mon, 27 Jul 2009, Aaron Boodman wrote:
>
> 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.

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?


On Fri, 24 Jul 2009, Nikunj R. Mehta 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?
> 
> 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. I 
> don't know about you, but I doubt it will work for an average Web page 
> author. Given its programming model, Oracle is not supportive of the 
> asynchronous Database and related interfaces.

Since the only way to communicate with workers is asynchronously, it 
doesn't seem to help authors much if we require that they put all their 
database calls on worker threads.


On Mon, 27 Jul 2009, Nikunj R. Mehta wrote:
> 
> This is certainly foreign to most database developers.

This API isn't intended for database developers. It's intended for 
front-end HTML developers.


On Mon, 27 Jul 2009, Nikunj R. Mehta wrote:
> On Jul 24, 2009, at 1:36 AM, Ian Hickson wrote:
> 
> > I think this is an important invariant, because otherwise script 
> > writers _will_ shoot themselves in the foot. These aren't professional 
> > database developers; Web authors span the gamut of developer 
> > experience from the novice who is writing code more by luck than by 
> > knowledge all the way to the UI designer who wound up stuck with the 
> > task for writing the UI logic but has no professional background in 
> > programing, let alone concurrency in databases. We can't be firing 
> > unexpected exceptions when their users happen to open two tabs to the 
> > same application at the same time, leaving data unsaved.
> 
> The above text referred to a certain class of developers as being unable 
> to cope with "unexpected exceptions". Most Web authors are not experts 
> at parsing specifications, I think you will agree. Database developers 
> exist as a class. Most database developers are not UI programmers, I 
> think you will agree. We all make generalizations and they are useful to 
> a certain extent. They help us do language design, and I feel that one 
> should identify the classes of developers and their 
> readiness/preferences.
> 
> The point is that database development is not new. There are already 
> programming models available that people rely on for using applications 
> in developing database-based applications. Why introduce yet another 
> one? Just because someone proposed it and no one was interested in 
> proposing another one? And we are talking here of standardizing one that 
> is duplicating what can be achieved though JavaScript and much simpler, 
> more conventional programming model.

I don't really understand your objection. What is the problem with the 
async database API?


> [Aaron wrote:]
> > 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.
> 
> Anything that is Turing complete, "can be implemented". So what? Since 
> when did the bar get lowered so much that only an existence proof is 
> required?

Actually the bar was raised to at least that high. It was lower before. :-)


On Mon, 27 Jul 2009, Jonas Sicking wrote:
> 
> Designing APIs for the web is different from designing APIs for many 
> other platforms. The fact that the resulting API comes out differently 
> than elsewhere is not I think we can avoid.

Indeed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 3 August 2009 10:37:35 UTC