[dojo-contributors] Dojo 1.9 Proposal

Jens Arps jensarps at googlemail.com
Wed Oct 31 12:38:09 EDT 2012


Hello,

as I am currently working on a CPM style module for a persistent dojo/store plugin, I wanted to share my thoughts on the whole storage thing.

Regarding localStorage performance:

That was a dreadful discussion. As I have posted elsewhere, I never experienced any perf issues from disk I/O, and I used localStorage extensively, also on old devices and weird prototypes. The only numbers that do exist about this seem to show that initial disk hit is not a real problem: https://insouciant.org/tech/time-to-load-localstorage-into-memory/

Regarding IndexedDB:

Sure, the store API is intended to be close to IDB. But IDB just isn't there yet. The spec still is subject to change, and there's quite a mixup of browsers out there using combinations of old/new version API, string/numeric transaction types and the likes... It is, however, possible to have an IDB backend today.

Regarding Synching:

I'd do a persistent store based on a memory store. This way, read operations use in-memory data. This, of course, means that there's a copy of the data set in memory. But, as soon as the user queries the store, this has to happen anyways. Even Sqlite and IDB impls, that do have the ability of querying, do not offer enough flexibility in that.

Other thoughts:

- the backend decision should be overridable by the user. For iOS WebApps one needs Sqlite, for large data chunks one needs IDB, for standard desktop uses one needs localStorage and so on...
- synching with a remote persistent store should not be part of it, that is application specific
- transactions and other overly complex concepts should not be part of it – we're providing a key/value store here
- old backends as IE userData or flash, as well as "exoctic" backends like widgetPreferences should not be included

I put the current state of the cpm module on github (https://github.com/jensarps/storehouse), along with a working localStorage and cookie impl, showing how the separation between backend and store is done. It still lacks the capability of handling async backends like Sqlite or IDB, though, but it passes the store/Memory tests, so this is a good starting point. My idea is that the backend returns values or promises, so that whatever comes back can be easily when()'ed.

Input on this is highly appreciated; maybe efforts can be shared on this.

Thanks,

Jens


More information about the dojo-contributors mailing list