I'm not particularly informed on this, but what makes this different then just hosting a text file and reading the text file? I wouldn't imagine anything needs to be specialized for this.
Because when you do it this way, you don't have to host the text file. This doesn't seem like a big deal when we're talking about 2048 saves, but a imagine a book reader or image editor.
Ah, so it works for the full API but not the chooser? or have they fixed the content servers? This is what Dropbox Support originally told me when I contacted them about the problem:
> Thanks for writing in. It looks like the issue here is that our content servers (dl.dropbox.com) don't currently allow arbitrary cross domain access in JavaScript. (This doesn't apply to accessing the file directly in your browser, or downloading to your server locally, which is generally what one would do with the link returned by Chooser.) […] This is something that would need to be enabled on our side, so I'll be sure to pass this on as feedback.
One of the big advantages (not really used in this sample) is conflict resolution. With a text file, if you make changes on two different devices while one (or both) is offline, you'd end up with a conflict and two versions of the text file.
With datastores, the changes are automatically merged according to developer-specified conflict resolution rules.
I actually tried to do something like this for a Comic Book reader, but the Dropbox API didn't allow for file requests to be made through JS: http://rkuykendall.com/articles/web-slinger-comic-reader/