Re: Assets cache invalidation

[Richard Hughes <hughsient gmail com>]

On 14 September 2017 at 11:06, Joaquim Rocha <jrocha endlessm com> wrote:
> leaves us with several copies of the cache throughout the time. For example,
> in my Fedora machine that I have been using for a while, I have:
>
>  ls ~/.cache/gnome-software/
>  3.19/        3.20/        3.21/        3.22/        3.23/        3.24/
> 3.25/        firmware/    screenshots/

"3.24  3.25  3.26  3.27" for me too, and 14Mb.

> I may not have the full picture about all the plugins that may need an
> invalidated cache on every new version, but I think that we could have a
> cache that's tied to an agreed incremental number instead... And to delete
> it altogether (or migrate it a bit more smartly) when it needs to be
> invalidated.

Cache invalidation is hard, and I agree using the major.minor version
is a poor mans fix.

> Perhaps it's also worth giving each plugin their own cache, for them to
> manage as they will. In that case we'd have a general cache (screenshots,
> etc.) and a different one for each plugin. The advantage is that we could
> invalidate the general cache without affecting the plugins'.

We kinda already do:

$ ls /home/hughsie/.cache/gnome-software/3.27/
extensions  firmware  flatpak  icons  ratings  reviews  screenshots
test  upgrades

We just call them a generic name rather than a plugin name. Maybe we
should do two things:

* The @kind in gs_utils_get_cache_filename() should be the plugin name
* The vername in gs_utils_get_cache_filename should just go

This means we'd create /home/hughsie/.cache/gnome-software/fwupd
rather than /home/hughsie/.cache/gnome-software/3.27/firmware

I think trying to manage the cache of the plugin outside of the plugin
is kinda crazy, i think each plugin just needs to be responsible for
cleaning up the cache if required at a good time, perhaps in the
_refresh() callback.

Richard