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. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
