Re: Storage API

[Bastien Nocera <hadess hadess net>]

On Wed, 2013-05-01 at 12:31 -0400, Colin Walters wrote:
> On Wed, 2013-05-01 at 16:31 +0200, Bastien Nocera wrote:
> >  Dumping
> > serialised Javascript objects to the filesystem isn't really elegant
> > either.
>
> It isn't, but for what it's worth that's what I do currently:
> https://git.gnome.org/browse/gnome-ostree/tree/src/js/jsonutil.js
>
> But this app is basically Tiny Data.  One starts to want SQLite and such
> when getting to Medium-Small Data and needing efficient indexing in
> process.

If a SQLite DB is used in the backend and the API is nice to use, there
should be no difference in usage between tiny and medium-small data.

It would be pretty nice to be able to scale if your application needs it
without having to rewrite code.

>   Finally on the Large and Big Data sides you're just doing RPC
> to some server.
>
> > I was wondering whether an API based on HTML5's IndexedDB[1] (and maybe
> > a GtkTreeModel to display the database contents/filtered results) would
> > be of interest in GLib.
>
> I don't have any experience with IndexedDB myself; on the surface it
> looks nice.
>
> This particular domain though is tricky because a "nice" data binding
> API really wants language-specific hooks.  The old pygtk treemodel
> binding had some smarts here.    

Sure. But even stuffing objects into a treemodel shouldn't be overly
complicated even if not optimal.

> Don't forget though you always have the ability to write a C library
> that does whatever you want (sqlite via C for example), and exports
> results to JS.
>
> There's obviously a lot of other stuff in this domain... libgda long
> predates introspection, but it claims to have something useful here:
> http://www.gnome-db.org/Bindings

libgda still uses SQL, making it not so nice for in-development
applications.