Re: Replacing WebSQL with a Relational Data Model.

Sorry Keean, the main point of my post was to introduce the [featurecreep
/], not critique your suggestions. I don't honestly care about the
implementation of persistent browser storage, but I do care that it's
fully-featured. nathan@webr3.org noted that we just need something to
persist data from javascript. Although I agree with this, I think we
additionally need native full-text search *as well as* CRUD. The Gears
implementation of FTS (or rather, SQLite) exposed useful functionality but
that needs
*
*
In hindsight it was a little off-topic, but I saw it fly past and thought
that while we were discussing offline storage features it'd be a good point
to raise FTS.

I'm also not sure about persisted JSON structures vs relational objects, but
happy to see how the current spec pans out. It certainly involves thinking
about an application's data architecture in a different way though.

On Wed, Oct 27, 2010 at 9:10 AM, Keean Schupke <keean@fry-it.com> wrote:

> Hi Nathan,
>
> On 27 October 2010 08:58, Nathan Kitchen <w3c@nathankitchen.com> wrote:
>
>> 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.*
>>
>>
> And I totally agree with this statement, which is why I think it is
> critical a _relationally_complete_ API is standardised (either in this, or a
> later IndexedDB spec, or another spec entirely).
>
>
> Cheers,
> Keean.
>
>