Decide on how to deal with assets such as pictures and other files #141

New Issue

davmo · 2023-07-02T22:50:11Z

davmo commented

2023-07-02 22:50:11 +00:00

Some shows refer to pictures and other files (example scripts, configuration files, etc). In the previous version of the HPR site these assets were placed on the server in a sub-directory with the same name as the show. However, when uploading such shows to archive.org (aka Internet Archive or IA), it was necessary to read recursively through all HTML relating to the show to find file references, copy them to the server doing IA uploads and include them in the list of files. Their URLs were rewritten to point to the IA copies.

Now we need to decide how to proceed now that we are short of space for storing many files.

Should these extra assets be stored with the static site HTML? (We are experimenting with this at present, stored in a sub-directory under the directory with the HTML.)
We have added an assets table to the database. Should details of these extra files be added to this table? The "find assets by parsing HTML" method was not 100% reliable because it depended on the files being represented as URLs, and some may not have been. This makes it desirable to store all associated file details here.
If we are to store details of all assets in the assets table, when should this be done?
When uploading shows to the IA, where should these extra assets be stored? The scripts which do this still assume that they need to hunt for HPR URLs and download files before uploading to the IA. It would be better (and safer) if the assets table guided this process. Alternatively, the stage where these files are being processed (archives being unwrapped, thumbnails being created, etc) could include the storage of these files on the server which will upload to the IA.
Shows on the static site could be modified to link to all related assets on the IA. This is already done for the audio files. Should this be the solution?

Some shows refer to pictures and other files (example scripts, configuration files, etc). In the previous version of the HPR site these *assets* were placed on the server in a sub-directory with the same name as the show. However, when uploading such shows to archive.org (aka Internet Archive or IA), it was necessary to read recursively through all HTML relating to the show to find file references, copy them to the server doing IA uploads and include them in the list of files. Their URLs were rewritten to point to the IA copies. Now we need to decide how to proceed now that we are short of space for storing many files. - Should these extra assets be stored with the static site HTML? (We are experimenting with this at present, stored in a sub-directory under the directory with the HTML.) - We have added an `assets` table to the database. Should details of these extra files be added to this table? The "*find assets by parsing HTML*" method was not 100% reliable because it depended on the files being represented as URLs, and some may not have been. This makes it desirable to store all associated file details here. - If we are to store details of **all** assets in the `assets` table, when should this be done? - When uploading shows to the IA, where should these extra assets be stored? The scripts which do this still assume that they need to hunt for HPR URLs and download files before uploading to the IA. It would be better (and safer) if the `assets` table guided this process. Alternatively, the stage where these files are being processed (archives being unwrapped, thumbnails being created, etc) could include the storage of these files on the server which will upload to the IA. - Shows on the static site could be modified to link to all related assets on the IA. This is already done for the audio files. Should this be the solution?

davmo commented

2023-08-21 15:26:10 +00:00

This subject hasn't been discussed - we've been very busy!

Created item #154 to suggest we fix existing shows as soon as possible. Preliminary investigation shows it might be possible to do it with webserver redirection.

This subject hasn't been discussed - we've been very busy! Created item #154 to suggest we fix existing shows as soon as possible. Preliminary investigation shows it might be possible to do it with webserver redirection.

Sign in to join this conversation.