I really like Dropbox. In fact, it's fair to say I love Dropbox. It's made so many use cases so much simpler. However, I am f*g sick of this perception that Dropbox is the silver bullet for every storage solution. This sort of sensationalism is just stupid.
Dropbox is a cloud-hosted, distributed system and just like any other large, distributed system, it's subject to some very real constraints in terms of latency and reliability.
In other words, it's not fair to claim that Dropbox is some magic silver bullet that will solve every scaling problem you're subject to, act like a rock solid filesystem which behaves identically to the one you have locally, or solve your love life problems.
Maintaining this perception is just going to create frustration for people who expect it to act this way, or worse, create a living hell for the developers maintaining the glue code between your system and the Dropbox API.
You try figuring out what the fuck is going on with your system when the "spooky" or "weird" version regressions start occurring. The arms will raise in a giant, collective shrug. Watch in horror as your http requests timeout because the roundtrip time between your box and Dropbox is that bad. The sodden faces of your product customers and the million "(so-and-so's conflicted copy of " files laying around your filesystem which JUST. KEEP. COMING. BACK. will be enough to make you wish you never drank the kool aid.
Now, I'm not saying that the Dropbox REST API isn't the best thing since sliced bread. All I'm saying is it has it's purposes and there are use cases and times when it simply isn't an appropriate choice.
In short, please respect the fact that distributed storage is a hard problem with hard constraints, stop proselytizing Dropbox as the 2nd coming, and relax and enjoy your backed up media and documents on your iPad already. Seesh.
I'm with you; I've already experienced various spooky things with desktop applications on top of Dropbox (like the excellent Papers2 by mekentosj) because of file conflicts and latency. And that's not Papers2's fault, since it would have to be redesigned to be tolerant of such things. But it goes a long way toward showing that Dropbox is not a syncing FS that can put any local application data in the cloud. In particular, Dropbox is bad for typical database use patterns (simultaneous writes, transactions) and the versioning and locking are not tunable.
Dropbox is a cloud-hosted, distributed system and just like any other large, distributed system, it's subject to some very real constraints in terms of latency and reliability.
In other words, it's not fair to claim that Dropbox is some magic silver bullet that will solve every scaling problem you're subject to, act like a rock solid filesystem which behaves identically to the one you have locally, or solve your love life problems.
Maintaining this perception is just going to create frustration for people who expect it to act this way, or worse, create a living hell for the developers maintaining the glue code between your system and the Dropbox API.
You try figuring out what the fuck is going on with your system when the "spooky" or "weird" version regressions start occurring. The arms will raise in a giant, collective shrug. Watch in horror as your http requests timeout because the roundtrip time between your box and Dropbox is that bad. The sodden faces of your product customers and the million "(so-and-so's conflicted copy of " files laying around your filesystem which JUST. KEEP. COMING. BACK. will be enough to make you wish you never drank the kool aid.
Now, I'm not saying that the Dropbox REST API isn't the best thing since sliced bread. All I'm saying is it has it's purposes and there are use cases and times when it simply isn't an appropriate choice.
In short, please respect the fact that distributed storage is a hard problem with hard constraints, stop proselytizing Dropbox as the 2nd coming, and relax and enjoy your backed up media and documents on your iPad already. Seesh.