W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [IndexedDB] Spec changes for international language support

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 22 Mar 2011 18:36:33 -0700
Message-ID: <AANLkTinG8ORdV=XqSo7RiASBKnbZo=9dYn8cNr57+osx@mail.gmail.com>
To: Pablo Castro <Pablo.Castro@microsoft.com>
Cc: Keean Schupke <keean@fry-it.com>, public-webapps WG <public-webapps@w3.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, Jungshik Shin <jshin@chromium.org>
On Tue, Mar 22, 2011 at 6:13 PM, Pablo Castro
<Pablo.Castro@microsoft.com> wrote:
>
>
> From: keean.schupke@googlemail.com [mailto:keean.schupke@googlemail.com] On Behalf Of Keean Schupke
> Sent: Tuesday, March 22, 2011 5:34 PM
>
>>> IMHO not the job of Idb to store the callbacks, so I don't see this complexity as a reason not to implement the API using callbacks. I think having one consistent API is more important.
>>> Specifying the collation 'name' has all the same problems as callbacks (needs to be re-done on every page, possibility of using different collations on different pages).
>>> Really a 'function' is just a symbol for a collation. A function name, is a better symbol for a collation than a string. Function's have a uniqueness property strings do not. So specifying a function as the >> collations instead of a string really is the same thing. Consider below:
>
> I don't think it's the same. If we don't store the callbacks in the database it means every page has to have full knowledge of the database schema (at least all the indexes) all the time, instead of just pulling that in on demand when needed. It also means we can never allow browser developer tools or generic dev-tool-webpages to modify the database because indexes would become invalid (not sure allowing tools to mess with the database in general is a good idea, but I thought it illustrated the point well).
>
> I wonder if the overall issue we're discussing has to do with "how embedded" the database is. In BDB scenarios where the database is completely invisible outside of an application many of these decisions make more sense. I don't think of web applications that way. I think of them more as a number of building blocks (pages, pieces within pages, tool pages added on the side) that are authored and sometimes even versioned independently, and the interface between those building blocks and the store is public and visible to tools and generic data browsers. All that changes the assumptions in the overall picture.

Yup. I Agree with Pablo here.

/ Jonas
Received on Wednesday, 23 March 2011 01:37:35 GMT

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