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

On Jul 27, 2009, at 12:43 PM, Aaron Boodman wrote:

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

Yes, but I included it for completeness sake.

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

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 think the odds are stacked against this one.

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

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


It has already been confirmed that requirements were not adequately  
described for WebDatabase [1]. This argument is, therefore, superfluous.

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

[1] http://www.w3.org/mid/4A43157F.10506@w3.org

Received on Monday, 27 July 2009 20:12:10 UTC