Re: Replacing WebSQL with a Relational Data Model.

I've been keeping up with the work you guys have been doing for a while and
I like the direction that the current spec is headed in. Although it ended
up being a bit of a dud, Google's Gears project got some cool functionality
out for developers to feed back on. The most obvious problem was that it was
tied so tightly to SQLite (which I think everyone would be amazed if MS
started shipping with IE10). They'd want to use Access/SQL Compact, and
suddenly we'd all have different SQL dialects to code our offline
applications to.

Which is why I agree 100% with this statement:

*The critical point here is that we need only one standardized interface,
> not a perfectly optimized for data-model-x one, not a uses
> query-language-foo one, just something that we can all use to persist data
> from javascript, and wrap in other APIs, that way any optimizations made
> will benefit everybody - regardless of their preferred interface, data model
> & query style.*


[featurecreep]
There is one more thing that I would like to see in the spec though:
full-text indexing/inverted index support. It's all well and good having a
standardized interface to build CRUD operations on top of, but I'd be
surprised if anyone is going to be able to build performant text search on
top of an API without *some level* of native support for it.
[/featurecreep]

I for one would love to see some consideration given to this for v1, it'd be
a shame to have to wait x-years until the spec is further developed before
this functionality could be added.

Thanks.

Nathan
On Tue, Oct 26, 2010 at 7:03 PM, Nathan <nathan@webr3.org> wrote:

> Jonas Sicking wrote:
>
>> On Mon, Oct 25, 2010 at 10:24 AM, Keean Schupke <keean@fry-it.com> wrote:
>>
>>> We (www.fry-it.com) produce websites and mobile apps. We have been
>>> looking
>>> at HTML5 for developing mobile apps, and for the kind of apps that we
>>> want
>>> to produce the client side WebSQL API provided what we needed. The
>>> IndexedDB
>>> is not suitable (no joins, no compound indexes etc...).
>>>
>> [snip]
>> One thing that I'm wary of is going the full relational route of
>> requiring that values be split up into columns. It's really nice that
>> javascript objects can be stored as-is, and then use key-paths to
>> access specific values within an object. But I think that should be
>> doable while still keeping the benefits of your proposal.
>>
>
> Likewise, personally all data I use is either in graph or k/v format, and
> have found (like many others), that primary speed gains come from changing
> the underlying data model rather than trying to map forwards and backwards
> between objects, graphs and tabular data in a relational data model, via
> SQL.
>
> However, over and above any issues of speed or this-vs-that, I strongly
> feel that universality should be priority number one, what all of us *need*
> is a /single/ standardized storage interface implemented everywhere
> javascript is, and certainly in all the major browsers.
>
> Keean, I think what you are proposing is great, but should be an API
> layered on top of IndexedDB, and which uses IndexedDB - the fact is we're
> dealing with javascript here, focus has to be on handling the structures
> provided (object/array) and getting them in and out of a persistence layer
> as optimally as possible.
>
> Thus, once we have this single universal persistence interface we can wrap
> it up in other model or context specific APIs (such as the one you
> describe), lessons can be learned, bugs filed, and over time speed increases
> and optimizations will be introduced.
>
> The critical point here is that we need only one standardized interface,
> not a perfectly optimized for data-model-x one, not a uses
> query-language-foo one, just something that we can all use to persist data
> from javascript, and wrap in other APIs, that way any optimizations made
> will benefit everybody - regardless of their preferred interface, data model
> & query style.
>
> Best,
>
> Nathan
>
>
>