Closed Bug 737414 Opened 13 years ago Closed 13 years ago

Update Dropbox provider to use new /media API call

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: mconley, Unassigned)

Details

Dropbox just sent out an email alerting me that the Dropbox API is changing (copy attached below). Should we be updating our Dropbox provider code? ---- Just a heads up that we are making the following change to /shares on Tuesday, March 20th, at 5 PM PST. Please email us at api-program@dropbox.com if you have any questions or concerns. - The Dropbox API Team ------ Date: Wed, Feb 1, 2012 Subject: Upcoming change to the '/shares' Dropbox API call We're planning on making a small change to the /shares API call to make it consistent with the documentation. Please make sure your app doesn't rely on the old behavior when it changes on March 15, 2012 (~45 days from now). What is the change? Currently, /shares returns a direct link to the contents of the file or folder itself. In the future, it will always be a link to a preview page — an HTML page with a preview of the file and the option to download it. Files shared from the Public folder will also return a preview page rather than a direct link. Who does it affect? Developers using the /shares call who rely on the returned link being a direct link to programmatically download the file contents. If you are generating the link for users to share with others then you won't be affected. What do I need to do? If you rely on the /shares endpoint to return a direct link, please switch to the /media call, which will always return a direct link. How long do I have? We will be changing the behavior on March 15, 2012. Please email us at api-program@dropbox.com if you have any questions or concerns. – The Dropbox API Team
We don't do this ("rely on the /shares endpoint to return a direct link to programmatically download the file contents" ). We let the e-mail recipient(s) click on the link and what happens happens. This is also old news; they've sent out this notification a couple times, and we've always followed the documentation, which has always been quite clear about what you get. This is one reason we can't just rely on content-location. Marking invalid; if I've missed something , please re-open.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Alright, cool, thanks. :)
You need to log in before you can comment on or make changes to this bug.