On Jul 27, 2009, at 12:43 PM, Aaron Boodman wrote:
On Mon, Jul 27, 2009 at 11:55 AM, Nikunj R.
Mehta<[email protected]> wrote:
On Jul 25, 2009, at 1:18 PM, Aaron Boodman wrote:
On Fri, Jul 24, 2009 at 6:51 PM, Nikunj R. Mehta<[email protected]
>
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/[email protected]
