In simple words, when you make a request in Jackett, the results are saved in memory (cache). The next request will return results form the cache improving response time and making fewer requests to the sites.
* We assume all indexers/sites are stateless, the same request return the same response. If you change the search term, categories or something in the query Jackett has to make a live request to the indexer.
* There are some situations when we don't want to use the cache:
** When we are testing the indexers => if query.IsTest results are not cached
** When the user updates the configuration of one indexer => We call CleanIndexerCache to remove cached results before testing the configuration
** When there is some error/exception in the indexer => The results are not cached so we can retry in the next request
* We want to limit the memory usage, so we try to remove elements from cache ASAP:
** Each indexer can have a maximum number of results in memory. If the limit is exceeded we remove old results
** Cached results expire after some time
* Users can configure the cache or even disable it
core: allow renaming & merging of trackers with config (part 1 #8355) (#8608)
* rename site field to id in yaml indexers
* add id field in c# indexers
* use id field instead of class name in c#
Really hope I don't break anything with this
Went to have a go at .NET core and it just became too confusing for me with 'Jackett' namespace referring to both Jackett.Common and Jackett
* Use platform detection that works on mono 4.6+
* Move to use package reference for restoring nuget packages.
* DateTimeRoutines does not have Nuget packages that support .NET Standard (and therefore .NET Core). We will have to include them for now until we can get rid of this dependency.
* Start spliting some interfaces into their own files - this will help by allowing us to split them out in the future into a seperate project so the actual implementations can stay within their respective architectures when required
* Move out common libraries
* Few more tidy up tasks to get things working with .NET Standard
* Restructure the solution layout
* Encoding work to reduce rework later on platforms without Windows codepages (or require compliance with RFC1345)
* Move folder structure around to have more natural layout of the solutions
* DI server configuration to get rid of "temporary" hack and dependency circle for serverservice
* Make all encoding consistent to match the expected encoding casing for earlier versions of mono.
Diego Heras