W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: [IndexedDB] Closing on bug 9903 (collations)

From: Keean Schupke <keean@fry-it.com>
Date: Wed, 4 May 2011 09:10:59 +0100
Message-ID: <BANLkTin8ZOe59etMBybQzHGq+hoiA2Sd4Q@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Aryeh Gregor <Simetrical+w3c@gmail.com>, Pablo Castro <Pablo.Castro@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On 4 May 2011 00:57, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, May 3, 2011 at 12:19 AM, Keean Schupke <keean@fry-it.com> wrote:
> > The more I think about it, the more I want a user-specified comparison
> > function. Efficiency should not be an issue here - the engines should
> tweek
> > the JIT compiler to fix any efficiency issues. Just let the user pass a
> > closure (remember functions are first-class in JavaScript so this is not
> a
> > callback nor an event).
> I don't think we should do callbacks for the first version of
> javascript. It gets very messy since we can't rely on that the script
> function will be returning stable values.

garbage in = garbage out. The programmers job is to write a correct
comparison function. All functions have this problem. By this argument we
had all better give up programming because there is a risk we may write a
function that returns incorrect results.

> Additionally we'd either have to ask that the callback function is
> re-registered each time the database is opened, or somehow store a

I still think re-registering is a non-issue. It is trivial to declare a
local open function "openNameIndex" than calls "openIndex" with the correct
callback and provide that as a software-module - either in the main code, or
in a separate JS file that can be included in each page. Modular programming
is a good thing, should be encouraged, and is the traditional software
engineering solution to this kind of problem.

serialized copy of the callback function in the browser so that it's
> available the next time the database is opened. Neither of these
> things have been done in other APIs in the past, so if we hold up v1
> until we solve the challenges involved I think it will delay the
> release of a stable spec.
> So the choice here really is between only supporting some form of
> binary sorting, or supporting a built-in set of collations. Anything
> else will have to wait for version 2 in my opinion.
> / Jonas

Received on Wednesday, 4 May 2011 08:11:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:19 UTC