[PATCH] Add XDG_STATE_HOME

[Bollinger, John C]

> I do not want to simply create more folders and a finer distinction between them. I want to add directories for types of files that don't fit really well in the existing structure (see my mail from June; there are quite a few, but history+logs are the most important to me, and they can be generalized to "state").

I suppose that it is a matter of opinion whether the proposed new category is a subset of one of the existing ones, then.

Of course, ALL files are data files in one sense or another.  The spec distinguishes two special sub-categories of data files -- configuration files and runtime files -- and it distinguishes between the remaining files based on whether they are "essential".  It further subdivides the resulting four categories based on whether files are user-specific, and then leaves non-user-specific runtime and non-essential files outside its scope.  I take the intent of the spec to be that that taxonomy should classify all files that desktop applications access or create when they run, and from that perspective I urge people not to be too hung up on the terms chosen to identify and characterize those categories.  It is the definitions, not the identifiers, to which one should pay attention.

Thus, I maintain that yes, carving out a new niche for certain kinds of files is creating a finer distinction within the existing system.

>> […] but this does not explain why $XDG_DATA_HOME is unsuited for such
>files.
>
> Do you really think applications should store their log files in $XDG_DATA_HOME?

Given one of the relatively few applications that maintain per-user log files that are not more specifically per-run log files, I think that it is satisfactory for that application to choose between $XDG_DATA_HOME and $XDG_CACHE_HOME based on whether it considers its log essential.  Per-run log files, on the other hand, are usually best stored in the application's working directory or alongside its input or other per-run output files, without regard to basedir.

> Personally, I don't like this idea at all. Some other distinctions between data and state:
>
> - State data may not be portable. You wouldn't want it to sync across machines.

Basedir makes no assumption that anything is portable.  Moreover, I take the "user" in "user-specific" to refer to a user account, on a specific machine, not to a person, and that also affords machine specificity.

> - State data may be less important. A data loss here may be an annoyance, but nothing as catastrophic as losing config or user data.

Basedir already provides for non-essential, user-specific data, with $XDG_CACHE_HOME.  Again, I suggest not reading too much into that choice of identifier: cache files are the canonical example of files appropriate for this directory, hence the name, but the spec designates this location for ALL non-essential, user-specific data.

> I reworded the relevant section of my patch to make it more clear what the XDG_STATE_FOLDER is about (re-formatted for the email; see the GitLab link for a full diff):
> ----
> The `$XDG_STATE_HOME` contains state data that should persist between
> (application) restarts, but that is not important or portable enough to the user that it should be stored in `$XDG_DATA_HOME`. It may contain:
>
> - actions history (logs, history, recently used files, …)
> - current state of the application that can be reused on a restart (view, layout, open files, undo history, …)
> - connection sockets (ssh, tcp, …) to be reused
> ----

It may be that it would be useful to replace the "essential" / "non-essential" dualism with a trinary distinction such as "must persist indefinitely" / "generally should persist" / "may persist".  The second of those would correspond to your $XDG_STATE_HOME (for user-specific files), and that characterization lines up with your one-time wording describing state files as fitting between data and cache.  I would have to give more thought to whether I actually support such a change, however.  I might be more favorably inclined if I had a less subjective argument for why drawing new distinctions would be useful -- are there functional or policy advantages to be gained, for example?

In any case, I definitely do not support characterizing any new category in terms of how important or portable the files it or other categories contain should be taken to be.  Furthermore, with regard to the specific examples presented, I note that sockets definitely belong in $XDG_RUNTIME_DIR. Also, existing applications already do accommodate most, if not all, of the other examples within $XDG_DATA_HOME and / or $XDG_CACHE_HOME, and it is not clear to me, in general, why they should not continue to do so.

Note also that changes to the spec are not free.  There is an existing, if thin, body of software that implements reusable support for Basedir, and changes such as are proposed obligate the maintainers, if any, of all such software either to update or to allow their software to fall behind the spec.  Of course, where maintainers opt for the latter, a spec change provides no benefit at all to those libraries' clients.


Regards,

John Bollinger


________________________________

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer