jgonera/fake_dropbox — pull request #3 by alexch (2012-12-05 19:21:45+00:00)
Title: keep track of a series of metadatas, each with a different rev

This is a followon to my previous PR; I put this in as a separate PR because the first one is less disruptive and you may want to accept that one while we talk about this one.

I extracted metadata handling into a separate object called Entry. In addition to cleaning up some of the code (e.g. extracting a `directory?` method instead of having `File.directory?(File.join(@dropbox_dir, path))` or whatever all over the place), this lets me keep track of a series of metadatas, each with a different rev. I need it since my app really cares about revisions as they happen over time, not just thinking of dropbox as a filesystem but as a feed of changes.

Naturally, a lot of stuff isn't implemented yet (notably, deletions, and the `revisions` API call) but I think overall it's a good move. Ideally there'd be an object overseeing the entire dropbox dir, and Entry would just handle the stuff about a single file or directory inside it.

The one part of this I'm ashamed/annoyed with is the use of a class var to hold the previously calculated metadatas. I need to do this because I was not smart enough to figure out how to get a persistent variable inside Sinatra, which makes a new instance for every request. I thought about using their `set` variable system but I think that happens too early on to be useful, since we don't know what `@dropbox_dir` is until later on in the process. Maybe it would work if I used a lambda setting value. Even if that does work, it would require more refactoring, probably so the thing we store is the DropboxDirectory object I mentioned earlier.