our current upload functionality is optimized for security, but because it intertwines the app server and file server roles, it makes multi server architecture more challenging. It also uses resources for permissions checking even on public files/images. Moreover, it makes it impossible to use service like heroku.
So...we need to support cloud files, and ideally we should be able to support both the current and other versions.
Wagn should support these mechanisms for viewing files/images. Note that even different revisions of the same card can use different mechanisms.
In 3-5, the content may be stored on the same server or another. In general none of the three should lead to wagn requests.
They correspond to these mechanisms for storing cards:
Unlike viewing files/images, which can all be options in the same deck, any given deck will need to have a single default storage option for creating/updating cards. (One configuration option in the future might present a dropdown for the user, but for now there is not much demand for that; it's much more important to keep things clean and simple).
the explicit (but unnecessary) configuration of current behavior
config.file_storage :protected # default
buckets are a bit more involved:
config.file_storage :bucket1
config.file_buckets({
bucket1: {
provider: ...
credentials: ...
directory: ...
},
bucket2: {
url_base: ...
}
})
bucket1 above is an example of a full-fledged cloud service. Ready for createing and updating files/images.
bucket2 is basically read-only. It would not be able to create/update images, but it would let folks render files and images and may help us support some cool data sharing patterns. (Eg, you could publish a set of image variants and switch to different buckets to get the different variants. Or you could have a dev server that didn't let you accidentally alter images on the cloud but let you see them. Or you could let someone use your "hand" of cards but not given them access to edit its images/files.
one valuable use case: development copies of a public website (eg WikiRate)
another valuable use case: Heroku deployments should work with this configuration!