[nl]

It starts a thread per (dynamic) request, with 25 second timeouts?

I can't imagine Dropbox will be too pleased running that on their servers (Although it is possible I'm misunderstand how it works - the explanation is vague, but I never knew Dropbox had the ability to run Python(!?))

[callumjones]

Dropbox can't run anything, this is meant to be run on your own hardware/vps/ec2.

[nl]

Mm yeah, that makes sense.

It also makes this incredibly bad. Not only do you have to run your own server, you have to pay for bandwidth twice - once from your server, and once from Dropbox (files are served from your Dropbox to the server, then to the client)

[LogicX]

Except Dropbox doesn't charge you for bandwidth. Imagine someone offering a service running this - plenty of other Dropbox hosting in the cloud services exist (such as to give you your own domain name tied to the Dropbox public folder)

[stanmancan]

Dropbox might not charge you for your bandwidth, but your server host will. Using something like this results in twice the bandwidth for every page served. You will be using your servers bandwidth to transfer the file from Dropbox to your server, and then from your server to the client.

[nl]

They don't charge you for bandwidth, except as part of their normal charges.

You can be sure they would cut off downloads if you started serving any significant traffic.

(Mainly because of the crazy-long opened connections. Bandwidth is so cheap now this system would fall over long before Dropbox started caring about that cost)