expand_less
Wagn should support these mechanisms for viewing files/images. Note that even different revisions of the same card can use different mechanisms.
coded files - db_content starts with ':'. These files are in the codebase, like the default logo. Every view is a wagn request.
protectedlocal uploadedfiles files – db_content starts with '~'. These These files are in the privatedeck's uploads"files" directory.directory Everyby viewdefault. is If aread wagnpermissions request. are
unprotected filesset –such samethat as"Anyone" above,can butread, withthen symlinkthere from public directory (symlink is availablea onlysymlink forfrom cardsthe thatpublic "anyonedirectory. can Otherwise read").every linkview is rendereda aswagn relativerequest. url.
"bucketed" files - db_content starts with '('. Eg "(mybucket)/123/4567.png". bucket is substituted for url base. rendered as absolute url
(?) complete urls - db_content starts with http (or other?). rendered as is.
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:
coded files are handled by coders (eg with rake tasks)
protected uploaded files are the default. (current functionality)
linking/unlinking to unprotected files is handled on permission-changing events.
this is standard cloud upload behavior
?
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).
Configuration
the explicit (but unnecessary) configuration of current behavior
config.file_storage :protected # default
buckets are a bit more involved:
config.file_storage :bucket1config.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.
coded files - db_content starts with ':'. These files are in the codebase, like the default logo. Every view is a wagn request.
unprotected
"bucketed" files - db_content starts with '('. Eg "(mybucket)/123/4567.png". bucket is substituted for url base. rendered as absolute url
(?) complete urls - db_content starts with http (or other?). rendered as is.
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:
coded files are handled by coders (eg with rake tasks)
protected uploaded files are the default. (current functionality)
linking/unlinking to unprotected files is handled on permission-changing events.
this is standard cloud upload behavior
?
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).
Configuration
the explicit (but unnecessary) configuration of current behavior
config.file_storage :protected # default
buckets are a bit more involved:
config.file_storage :bucket1config.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.