Re: Replacing WebSQL with a Relational Data Model.

On Tue, Oct 26, 2010 at 12:02 AM, Keean Schupke <keean@fry-it.com> wrote:
> Hi,
> It will be a lot faster with SQLite as the backend. Mobile apps depend on
> access to the SQLite engine, and although it _could_ be implemented on top
> of IndexedDB, there is no way its going to be fast enough... And the thought
> of writing a decent query optimiser is a bit daunting.
> The benefit of making it a standard, is that browser implementers can do
> what they want, implement in JavaScript on top of IndexedDB, or pass through
> to a proper database.
> BTree's are old hat in the database space. Modern storage engines are using
> Fractal-Trees for a 50-80 times speedup in write performance. The browser
> should not be trying to compete with experienced database coders.
> The relational storage model I am proposing will return a database table as
> a list of objects, where each object represents a row, and the object has a
> set of named properties representing each column.
> Part of the power of the Relational Data Model is that it abstracts data
> into columns and tables, and this is precisely what we want.

I think you are misunderstanding what I'm proposing.

The problem is two-fold. I don't think we want to create a entirely
new database backend. We already have two different APIs (three if you
count localStorage), and none of them have full buy-in from all major
browser vendors. Adding a third one, and on top of that one that is
more complex than all other ones that have been suggested, I don't
think would be successful.

However I do think that what you are proposing could be done as
additional API for the IndexedDB spec. However since we are currently
trying to finish up the currently discussed feature set, I don't think
we want to take on what you are proposing *at this time*. I do however
think that it's something we should look into for the next version of
IndexedDB.

In the *meantime*, what you could do is build *prototypes* in
javascript on top of IndexedDB. This would have several benefits:

* It would be easier for everyone to understand exactly what is being
proposed as we could look at your prototype implementation.
* It would give web authors something to experiment with so that they
can say if they like it or not. Or if they would like something
changed.
* It would allow us to profile to see which parts are slow and so that
we can prioritize those areas first for specification in IndexedDB v2
and native implementation in browsers.

So I'm not saying that IndexedDB in its current state is enough to
build what you want and get good performance. I'm saying that I think
a prototype implementation on top of IndexedDB would be very
educational.

Of course, if you disagree and think writing a separate database
interface is the better way to go, then don't let me stop you. You are
totally free to write a specification and I'd imagine W3C would be
happy to publish it. I'd think it would fit under our current charter
and so very little red tape is needed.

/ Jonas

Received on Tuesday, 26 October 2010 08:43:31 UTC