Cache directory tagging proposal, version 0.2
baford at mit.edu
Sun Jul 25 13:50:02 EEST 2004
Colin Waters wrote:
>On Fri, 2004-07-23 at 00:19 +0200, Bryan Ford wrote:
>> While nothing really substantive has changed in this version, I've fleshed
>> the introduction and Alternative Approaches sections, particularly in order
>> to clarify the reasons it is not sufficient just to standardize the
>> where applications place their caches,
>I'm not so sure about this. I think it could be quite useful to try to
>standardize something with the FHS. This problem is very obviously in
I fully agree - I didn't say that we _shouldn't_ try to standardize the
location of caches, only that it's insufficient by itself - at least in the
short term when there are not only conflicting standards, but also apparent
technical conflicts between the goal of standardizing directory structure and
the goal of allowing user configurability. I fully support the FHS and xdg
basedir standardization efforts; right now I'm just trying to pick a
low-hanging fruit that might make our lives a little better immediately with
very little effort.
>The major problem with /var/cache is that it's not per-
>user. The solution to that is to have something
>like /var/cache/users/$USER. Once the FHS has standardized it, we can
>change the xdg basedir spec to default to that (if it exists).
Agreed - that sounds like a good approach to me.
>However, even if the FHS standardizes it, deployment will take some
>time. In the meantime, .IsCacheDirectory makes sense as a transitional
>mechanism for FHS systems, and would remain useful on non-FHS systems.
And even after the location of application caches becomes more standardized, I
think we might still find use for standardized cache directory tags, but at
that point not so much for identification purposes as to allow applications
to communicate semantic information about their caches to global system
utilities. For example, a future version of this proposal might allow apps
to write tags such as the following in their cache directory tags:
Creator: <name of creating application>
Longevity: <number of seconds, days, or whatever>
- indicates to system utilities that any file in this directory
more than N secs/days/whatever old is fair game
to be deleted by a nightly cron job.
The latter tag would in particular provide a solution to the current problem
that currently if a user runs a caching application once, then never runs it
again, the application's cache basically stays around forever because only
the application itself can normally expire its contents. With such an
extension, the system could actually expire the contents of old caches in a
way that avoids interference with the app's cache management policies.
Anyway, I'm not proposing to add such extensions right now, and not trying to
start a discussion on the details of such extensions at present; the above is
just an illustration of how I imagine cache directory tags might still be
useful even in a future, better world where all apps keep their caches in a
More information about the xdg