Add IndexedDB support

[alekseykulikov]

I want to suggest new big enhancement for this library and full-fledged support of html5-offline. Library should automatically use IndexedDB if it's possible and switch up to localStorage for older browsers.

Helpful links:

• http://www.w3.org/TR/IndexedDB/ - w3c specification for IndexedDB
• http://www.html5rocks.com/en/tutorials/indexeddb/todo/ - example of usage
• https://github.com/superfeedr/indexeddb-backbonejs-adapter - interesting IndexedDB adapter for backbone.js (as starting point)
• https://github.com/jensarps/IDBWrapper - Good cross browser wrapper

I know that IndexedDB is still draft and API looks strange in some areas, but I think that localStorage is temporary decision for offline-apps and I want look ahead the future. If someone want to implement this challenge, please contact with me, and we will try to imagine main points together.

[abuisman]

I think that amplify.store is a pretty decent alternative to the offline storage that is in here now. It is (should be) pretty cross browser.

There are some attempts at porting the localStorage plugin that was used in offline to amplify.store. Some pretty successful. I'll have a stab at making this work in Backbone.offline.

Source: http://amplifyjs.com/api/store/

[alekseykulikov]

It's perfect idea and It will great if you add patch for aplify.store.

But I think IE6-7 support should be optional. When user included aplify.store + json2 then we're using amlify. https://github.com/appendto/amplify/blob/master/store/amplify.store.js

When user included IDBStore and browser has IndexedDB support then we use it: https://github.com/jensarps/IDBWrapper/blob/master/IDBStore.js

So we can give user ability to configure which storage-adapter he wants to use. In Offline.Storage I have methods setItem, removeItem and getItem. We can extended them for more complex behavior.

[g00fy-]

This is not so simple, IndexedDB & websql are async, this means that you can not do this with current implementation.

[abuisman]

The other day I created a little adapter for Backbone.localStorage. https://github.com/abuisman/Backbone.amplifyStorage

Might come in useful for someone.

[alekseykulikov]

@abuisman, thanks for share

[abuisman]

@Ask11 My pleasure. I hope you find it useful.

[rogeriochaves]

Hello, I just made a modified version of backbone.offline to use IndexedDB, it worked very well for me, I basically hadn't to change anything on my backbone code, just backbone.offline file and added the YDN-DB library.

Check it out: https://github.com/rogeriochaves/backbone-indexeddb-offline

It wasn't fully tested, any errors let me know :)

[abuisman]

@rogeriochaves

Thanks for sharing! Nice work on keeping this going.

What I wonder though is what motivated you to basically fork backbone-offline rather than writing an adapter for it like I did (see above). I compared the code of your fork and the original and there are many similarities. You could have written a new class that inherits from the original and then just override what you need.

More generally: When we look at these efforts we might even be able to distill a storage-independent solution and work 100% through adapters.

This way backbone-offline will not define what you have to use as storage, but just provide you with an interface for the backbone piece of the puzzle. Adapters (which should be more modular than mine maybe) should then provide the actual storage piece.

What do we/you think?

p.s. If I am not mistaking: in your first method localSync you have if method == 'read' and later you have a switch with when 'read', but this will never be true, as the if would've passed and the switch is in the else.

[rogeriochaves]

@abuisman

The thing is the current backbone.offline implementation was not async, and IndexedDB is, so I had to change many things to work properly, it was easier to me to change the code. But the code I made uses YDN-DB, which unifies IndexedDB, WebDatabase and WebStorage, so, change the storage now is easy (although I didn't tested with others storages yet).

But it is definitely a good idea to separate the backbone.offline core from it's storages, since storages specifications may still change, and the modules should worry about working with the browser, while the backbone.offline should worry to work with the current version of backbone.

Still, although it's a heavy library (about 100kb with the 3 storages), I liked very much to work with YDN-DB, because it's well maintained and it is so easy to use.

About the p.s., I putted that if method == 'read' because it was the only method I really had to work asynchronously, and I forgot to remove it from the switch. Changed it already, thank you!

[abuisman]

Yes I see what you mean.

I guess it depends on how @ask11 feels about updating backbone-offline to work more modularly and allowing for modularity in picking storage engines.

Then again, it also depends on how much effort we all need/want to put into this. I mean if solution xyz works for someone, why think about and work on more of them? Also, it might even have a place within the backbone project to allow modular storage engines.

@rogeriochaves what would be great is that if you'd have some comprehensive tests so that we are able to automatically check whether your solution still works when backbone updates.