Link to PDF file changes when file is replaced
+example
http://wikirate.org/Business_contribution_to_the_SDGs_A_student_assessment which currently holds this link: http://wikirate.s3.amazonaws.com/files/3085430/13433241.pdf, but used to also hold this link http://wikirate.s3.amazonaws.com/files/3085430/13433135.pdf and another one I can’t find.
+Discussion
We used to support permanent links. Now we don't, but perhaps we should again.
Let's pretend the name of this card is "businessment" (real name is too long). When files are stored locally on Decko, you can do things like "/businessment.pdf", and it will figure out which file was wanted and return the current version. But since WikiRate now stores files remotely (on a cloud server), we need a different solution if we want a permanent url that always takes you to the right place.
There are basically two options: redirects (easy) and tunneling (way less easy). Short version: unless you have a really good reason to solve this with tunneling, I think we should do redirects.
With redirecting, you could share the /businessment.pdf url, and it would redirect to the url of the current version on the cloud server. So a "dynamic" url would redirect to a "static" one, and the person you gave the url would end up with the static one in her browser. That's the biggest downside: by the time they get the file, they're looking at a non-wikirate.org url.
Tunneling would mean we'd make /businessment.pdf work from start to finish (no redirecting) by pulling the file from amazon, through the wikirate server, and then out to the user. It would require more resources, both from the developers and the server. But the person you gave the wikirate.org url would be able to keep the url all the way through.
As far as I can tell, you never get to the file without being redirected to the non-wikirate.org url.
Redirecting seems like a good solution then since the biggest downside is already the current downside. Or even if I'm misunderstanding that aspect, it still seems like redirect is a fine solution. Doesn't make sense to be dedicating a lot of resources to this.
ok, cool
This will be obviated by the new source handling (coming next month, we think)