[PATCH] Add XDG_STATE_HOME

[Jonas DOREL]

NB: Sorry for previous encrypted messages


I think one of the main benefits of the XDG_BASEDIR is that we can apply

different policies to those folders, instead of having to go through
each application directory. So to understand why (or why not) the
XDG_STATE_HOME would be useful, I think we should specify the policies
we might want to apply to each kind of file.


In my opinion these are the distinctions that should be made about data:

  - is it lost if deleted ? If NO: go to $XDG_CACHE_HOME

    - can be deleted to retrieve disk space (no backup)

  - is it static configuration data ? If YES: go to $XDG_CONFIG_HOME

    - can be audited easily (+ backup + sync)

  - is it something that stores some application state ? If YES: go to
XDG_STATE

    - can be removed to restore default state in case the application
becomes unusable or startup crash (no backup)

    - can be synchronized between hosts to have a painless computer
switching experience

  - else: go to XDG_DATA (for backup)


In this regards, here is where I think the mentioned data should go:

  - application logs: XDG_DATA_HOME

  - user actions history (commands history, recent files): XDG_DATA_HOME

  - application layouts (different from view): XDG_DATA_HOME

  - session settings (opened files/projects, current view) used when
restarting the application : XDG_STATE_HOME

  - sockets: this is a special case, because sockets should go in
/run/user/$USER_ID. But some applications don't support variables in
config files, hence it could go in $XDG_STATE_HOME


Although we might want to implement retention policies on application
logs and user actions history, file format heterogeneity  would make it
extremely difficult, so splitting this away from XDG_DATA wouldn't have
a big impact.


About your specific points:

> Do you really think applications should store their log files in
> $XDG_DATA_HOME? Personally, I don't like this idea at all.

Why don't you like this at all ? I consider my command history to be
important and part of the data I do backup on. How would you treat your
history data differently ?

> Some other
> distinctions between data and state:
>
> - State data may not be portable. You wouldn't want it to sync across
> machines.
I agree, but if you application data is not portable, you might want to
sync it between some systems and not others. And how do you judge
portability (should work on all UNIX systems, on WINDOWS systems, ...) ?
> - State data may be less important. A data loss here may be an
> annoyance, but nothing as catastrophic as losing config or user data.

How do you judge how data is important ? Some don't care about history,
some do; some don't care about applications logs, some do, ...

I don't think we can use this as a criteria for separating data in
different folders. (We could however create a naming scheme to be
followed by applications in the XDG_DATA_HOME).


Overall, I don't think XDG_STATE_HOME should exist, considering the only
two reasons (from my perspective) for it to exist would be:

  - exclude from backups (I don't think state data takes that much
space, and some people might want to keep it)

  - synchronize between hosts depending on architecture and installed
application version

    - I think applications should store state data in a folder with a
unique scheme per architecture / version


However, I think we should explicit the following usage for the
CONFIG_FOLDER:

  - XDG_CONFIG_HOME is for static configuration not changing at each
user session


And add the following to the XDG_DATA_HOME:

  - user actions history files is data

  - application logs is data


Initially, my main usage of XDG_BASEDIR is to not clutter my $HOME, so I
would have liked to have a $HOME/.applications folder. But, there are
advantages to have $XDG_CONFIG_HOME and XDG_CACHE_HOME:

  - the benefit from having XDG_CONFIG_HOME split from XDG_DATA_HOME is
that you can use a VCS with it.

  - the benefit from having XDG_CACHE_HOME split from XDG_DATA is that
you can regain disk space by deleting everything inside easily (no regex
to target every cache folder in the application folder).


However for STATE_DATA and HISTORY_DATA, backup and sync policies are
different depending on user and application, so a single $XDG_STATE_HOME
wouldn't improve the situation


PS: I also think there should be another distinction, but that we
shouldn't discuss it in this thread.

  - is it something that you want to keep out of disk space of this
computer ? If YES: go to XDG_SECRETS_HOME

    - permit storing this folder with restricted access permissions on a
different disk (or fetched online and stored in tmpfs)


--

Best regards,

Jonas DOREL