Re: [IndexedDB] Spec changes for international language support

I think thats an out-of-date view of web-apps. They are just JavaScript
programs hosted within the web-browser. You can have a 'module' that
provides an applications-specific database API.

However, lets say I am running a shopping cart. I can have methods like
'addToCart', removeFromCart. I then define a module:

// in mycart.js
function myCart() {
    //initialisedb and callbacks (all inside the closeure).

    return {
        addToCart: function(item) { /*...*/ };
        removeFromCart: function(item) { /*...*/ };
    };
};

Now on each page I do:

<script src="mycart.js"></script>
<script>
    mycart = myCart();

    mycart.addToCart('item1');
    mycart.removeFromCart('item2');
</script>


I think every 'page' should have full knowledge, as I think IDB should be
entirely schema-less. If we use functional modules as above, its not a
problem.

To me an SQL like relational database is more suited to the task that you
are describing (where tools can add/remove data). In SQL triggers and stores
procedures can ensure consistency of the data. Without triggers, the tool
may remove an object referenced by another object in a different
object-store for example.

My concern is that IDB seems to be heading towards recreating the features
of an SQL database, but badly. Slowly the feature set is creaping towards
full blown SQL (with relational queries, and stored procedures), but
ignoring all the work and experience that lead the database community to
standardise on SQL.

The API of something like BDB represents a small light and low level API
that avoids 'partial' features. Even BDB now supports SQLite-3.0 API, (with
better concurrency than SQLite).

I thought the idea was to provide a low-level API than other people can
implement libraries (providing API-flavours to users) on top of.

In which case look at how the SQLite-3.0 API is layered on-top of BDB. It is
a master-class in which functions should be in the high-level and which
functions should be in the low-level APIs.

Please, lets have a nice simple low-level browser API, and keep the
high-level stuff in libraries. If particular people feel strongly about
certain high-level features, then by all means include a library with those
features in your browser bundle.


Cheers,
Keean.




On 23 March 2011 01:13, 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.
>
> -pablo
>
>