Cache media by type

@fox,

What are your thoughts about updating rssutils::cache_media() to selectively cache media by type? I was thinking media could be grouped by image, audio, and video (since that’s what the XPath query searches for). Either a global setting in Preferences or tunable/constant could be used where the admin could define what enabling “cache media” does. Default would be everything (like it is now), but a defined constant (e.g. CACHE_MEDIA_TYPES) could contain a string like 'image,audio' to allow caching only images and audio (not video).

I’d be willing to submit a pull request in the near future, I just wanted your feedback before I tackled it.

since local files are auto-used when they are available for hashed URL i think this could be easily handled by a plugin without any core modifications. unless i’m missing something (imgproxy does something very similar to that only the criteria is different).

i.e. plugin sits on article filter, downloads stuff into normal cache directory based on its settings and then it just works

The idea was that the administrator of the installation could allow/disallow media.

I guess this could be handled by a plugin but if the user chose to cache media for a feed that served 2 GB video files the plugin couldn’t really hook before and after cache_media() prevent that. So for example: if the admin does not want video files downloaded to the server, cache_media() is still going to find the tag and try to cache the file. A plugin could swap //video/source for something else so it doesn’t get cached but then it would have to switch it back to a video tag and the only hook after that is sanitize, seems clunky.

oh I thought the idea was to cache all audio or whatever, the admin option makes a bit more sense, however given the target audience of ttrss i.e a personal reader or one for a bunch of friends (as opposed to a faceless cloud service) I’m not sure this is needed.

if your user keeps caching 2gb files tell them to stop this shit etc