Cache directory tagging proposal, version 0.2

[Bryan Ford]

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 
out 
>> the introduction and Alternative Approaches sections, particularly in order 
>> to clarify the reasons it is not sufficient just to standardize the 
locations 
>> 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
>their domain.

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.

Exactly.

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 
standard location. 

Cheers,
Bryan