W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: Replacing WebSQL with a Relational Data Model.

From: Jeremy Orlow <jorlow@chromium.org>
Date: Wed, 27 Oct 2010 10:27:38 +0100
Message-ID: <AANLkTinAu5cmLZ1f=+eqPDLFNPUYE-bezuA6sak4kW5Y@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Keean Schupke <keean@fry-it.com>, nathan@webr3.org, public-webapps@w3.org, Arthur Barstow <art.barstow@nokia.com>
On Wed, Oct 27, 2010 at 9:24 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Oct 27, 2010 at 1:04 AM, Keean Schupke <keean@fry-it.com> wrote:
> >> So, my point was that although IndexedDB is neither optimal for your
> >> preferred data model or mine, it does cater for us both, and everybody
> else,
> >> allowing us to get on and do our jobs, implement APIs, and build HTML5
> >> client side web applications.
> >
> >
> > This is where we differ, as I think it may allow it, it will not make it
> > practical (from the programmers point of view) nor usable (from the end
> user
> > tying to use the app).
> > Remember we have to perform reasonably against native iPhone / Android
> apps
> > or people will not use HTML5 apps.
>
> I'd encourage you to do some testing, run some performance numbers,
> and report back for cases where things are too slow.
>
> That good performance is a required in order to consider a use case
> met is hopefully obvious to everyone here. The whole point of
> IndexedDB is good performance, other than performace it doesn't
> provide anything that localStorage doesn't.
>

This statement is a bit misleading.  The reason it'll be faster is because
many of the features in IndexedDB would have to be implemented as a scan
through the entire storage in LocalStorage.  Other than them being k/v pairs
and persistent, they're really completely different.  IndexedDB is not
simply the fast version of LocalStorage.

And at least with WebKit/Chromium, we're pretty slow and we know it--much
slower than both LocalStorage and WebSQLDatabase  But we're more concerned
about getting the API implemented so we can iterate on that rather than
performance at this time.  Once the API is done, we plan on spending a lot
of time on making our backend faster.

J
Received on Wednesday, 27 October 2010 09:28:33 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:41 GMT