At this point they should start putting some spin on it.
"Help your company employ more people. Dropbox for Business's lack of administration tools will grow your headcount. When you see your admins waiting for a list of users to load, or trying to write their own tools based on scraping the website, feel good about how you're fighting unemployment."
I don't suppose there is a way to programmatically consume the activity stream and pick events to undelete, too?
I'm sorry I can't edit the smug sassiness out of my original reply.
I'd love to recommend using the new Dropbox comments feature but I can't until I know there is a way of getting that data out after putting it in. I'm not entering metadata into a system that doesn't have fully programmable export. Been burned too many times.
Pretty please?
I would like my web server to be able to slurp up all the images from my customer's Dropbox. Unfortunately, shared folders can't be downloaded if they are larger than 2Gb, which is quite often for me.
Is there an API suitable for this?
EDIT: oh yes, yes there is! https://www.dropbox.com/developers/chooser
EDIT 2: It would be sweet if you guys also exposed SHA2 hash of the files in Choser. Often times they user will mistakenly load the same file, and I would rather not do the work at all if I don't have to.
Git annex automatically uses SHA256 on all files as the UUID (optionally set SHA512 in .gitattributes). You can PGP sign your git commits to add more verification.
Plus you dont have to trust a 3rd party with your data, as it can sync entirely over local networks via SSH, directly to a USB harddrive, and it supports encryption when using S3 or other cloud storage.
I managed to teach my non-technical girlfriend how to use it without much effort but getting business people to use it might be a hurdle.
Aw. All grown up.
It's too bad their JavaScript SDK isn't ready yet but making HTTP calls from JavaScript is dead simple so that's not the worst thing.
Overall looks like a good set of priorities for what SDKs got done first.
I'm only half joking there :)
In all seriousness, though, it did make my brain tilt about 15 degrees to see the words "JavaScript" and "SDK" next to each other like that.
What's the problem with a POST based API?
I've done REST and "rest" for many years and every single time it starts out really simple. Oh I just need the profile data so let's make a RESTful endpoint just for profile. So easy! Oh wait the profile page need data from X, Y and Z. Well we gotta be RESTful so let's make 4 HTTP calls. Oh, latency sucks on mobile and terrible networks and we have to cut down on HTTP calls? Sorry, can't, we're RESTful...okay fine ONE RPC endpoint for the profile page's information.
I think REST has it's place; it's good if you want a really intuitive way to access a very specific resource. Beyond that? For developing web apps? Almost always have to go down the RPC route and there is nothing wrong with that. Not everything has to be "RESTful" damn it!@
I agree with your point about REST though, it's not even a standard. If it was there would be no debate about what REST is and what it isn't. It's a vague set of idea and its author himself kind of said his paper was targeted at "specialists" and not classical "developers".
People keep on telling me "read the spec", well there is no normative spec.
On the other hand, I've never much cared about the "no true REST" crap that the conversation always seems to turn into. I'm too pragmatic to care if I'm adhering to someone's concept of a convention.
OTOH, since your data is accessible to anyone after they push "return true" as their auth mechanism, I guess it doesn't really matter. If they offered proper encrypted storage, it'd be much more important.
Though even without encryption, a closed-source client that auto-updates leaves one big hole: They can push an update to specific users or activate code for them. With an open source client, that part could be mostly avoided.
Unfortunately, Tarsnap seems to be the only contender in this area (trustworthy backups). On Windows, this means using VMware shared folders.
I really like how Cryptomator works, and I think Dropbox could easily provide similar functionality, and perhaps in an even more user-friendly way, too, since they can just integrate it with their Dropbox app, rather than this functionality being in a whole separate application.
Dropbox is not an advertising company like Google. They still have some of the highest fees for cloud storage around. So why do they care about seeing what's in people's files? Why not allow people to encrypt the files locally before uploading them?
And lest we forget, in the PRISM slides, Dropbox was mentioned as "coming soon". So unless they want to admit they are already part of the PRISM program, then what better way to dispel those rumors (not made any better by getting Condoleezza Rice on their board) that they are cooperating with the NSA.
http://www.zdnet.com/article/fbi-nsa-said-to-be-secretly-min...
...until you close it for grinding too much cpu.
Everything about this should be open source, and I won't ever use it until it is. Also they should make a lot more effort towards promising privacy and security. As it stands right now, they seem intent on handing your file access to governments and building systems that are insecure by design. No thanks. Open source and then we'll talk.
