On Aug 5, 2011, at 10:10 AM, Holger Protzek wrote: One solution in my mind, is to create for every document in the couchdb, a json file in the dropbox, with uuid as filename. On programm start I check for new files in the dropbox. So new or updated documents will be merged in the local database.
That's headed down the slippery slope of re-inventing CouchDB replication from scratch, and on top of a data store that doesn’t have the necessary infrastructure (multiple versions, and tracking sequence numbers). Consider that * You don’t just have to check for new files in Dropbox, you have to check for existing files with a newer mod date than the copies you have. * If both a local file and a copy on Dropbox have been updated, you have no way of recognizing a conflict and will end up overwriting one with the other. * How do you tell the difference between a remotely added document and a local deletion? I’ve thought about this a bit, and the simplest external storage system that makes sense is to store a list of *changes*: a remote document to which every client appends descriptions of what they changed (created doc ID xxx with these contents, updated doc ID yyy with these contents, deleted doc ID zzz…) You need to remember the prior EOF of the document so you can recognize if it’s been changed before you try to append your own changes. (This is actually quite feasible with HTTP using ETags.) Something like this might be possible using DropBox, by using a file per change instead of one long file, but I haven’t thought of the details. —Jens
