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: Tue, 3 May 2011 15:56:10 +0100
Message-ID: <BANLkTikHS5XNHpn7pEt+v9g4K8a86nv8sQ@mail.gmail.com>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Pablo Castro <Pablo.Castro@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Why does it need to be persisted? I would prefer the database to be
stateless. Obviously all users of the database need to use the same
function. I would recommend modular programming - create a .js script you
can include in all pages that provides 'collated' versions of the method
calls by adding the collation argument - Infact for good programming in
general make this API your model, so if you were writing a shopping cart,
this '.js' would provide methods like 'addToCart', 'removeFromCart', and all
collations settings would be hidden in this layer and kept out of individual
pages, whilst not needing to be stored in the database at all.


On 3 May 2011 15:27, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote:

> On Tue, May 3, 2011 at 3: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).
> Wouldn't it be a bit more complicated than just passing a regular
> closure?  The function has to be persisted in the database across page
> views, but a JavaScript closure is going to contain references to all
> sorts of objects (like document, or local variables) that are very
> specific to the current page view.  It makes no sense to persist those
> objects in general.  You'd need to serialize the function somehow,
> possibly putting restrictions on the sorts of variables it can access,
> so that it can be sensibly restored later.  Is there some established
> way of doing this yet in JavaScript?  It might be useful in other
> contexts too.
> I still agree that this is the correct direction to go in, though.
Received on Tuesday, 3 May 2011 14:56:37 UTC

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