Consider using the xdg specification about cotp HOT 6 CLOSED

Hi all. I like the idea of using the XDG specification, of course falling back to previous directory for backwards compatibility.

I would use XDG_DATA_HOME because:

• XDG_STATE_HOME is more unused, and added in a next revision in 2021: Free Desktop 0.8
• I found it more relevant and it's used widely by other applications. In this case, the specification is not clear on what data and state means.

Please let me know your thoughts.

from cotp.

Implemented in #337

from cotp.

Hello, @tomasol,

The App itself already supports to read an environment variable named COTP_DB_PATH. I'm not sure if this meets your needs...

cotp supports portable mode and specify of the db location:

The app will check the COTP_DB_PATH variable 1st, then check the .cotp/db.cotp in the App folder(working directory), and finally the default path of the user folder.(%userprofile%\.cotp\db.cotp on Windows, the ~/.cotp/db.cotp on Linux)
TLDR: to use portable mode, make sure .cotp folder exists at the same place where the App executable is.

from cotp.

Having the app specific COTP_DB_PATH is nice for some use cases, but that isn't a substitute for XDG support, which should come first. The hard coded .cotp/db.cotp should be preceded by a check for if a relevant XDG variable is set, and use it if it is, and probably then default to .local/share if it isn't instead of .cotp.

1. If COTP_DB_PATH is set, use that as the full path.
2. If $(pwd)/.cotp exists, use that prefix for portability mode.
3. If ~/.cotp exists, use that prefix for backwards compatibility but warn the default location has changed.
4. Check if XDG_DATA_HOME is set, if so use it as prefix with $XDG_DATA_HOME/cotp.
5. If not, set the hard coded prefix to .local/share/cotp

from cotp.

@PM2p5 here is a writeup regarding why following the XDG specification might be beneficial.

@alerque I agree with your proposal.

One thing that I might have gotten wrong is the category to which the database belongs to:

From the spec:

There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME.

There is a single base directory relative to which user-specific state data should be written. This directory is defined by the environment variable $XDG_STATE_HOME.

Arch wiki:

XDG_DATA_HOME
Where user-specific data files should be written (analogous to /usr/share).
Should default to $HOME/.local/share.
XDG_STATE_HOME
Where user-specific state files should be written (analogous to /var/lib).
Should default to $HOME/.local/state.

And finally xdgbasedirectoryspecification.com

Data
General files and data that is inherently portable across computers. Examples include fonts, files downloaded from the internet, and desktop entries.
State
Files that hold the state of the application. This may include logs, command history, recently used files, and game save data. In other words, if the data is unique for a given machine, the file belongs here.

Now I think it should be in XDG_STATE_HOME rather than XDG_DATA_HOME. WYT?

from cotp.

I have heard several explanations and not all of them agree with each other. In fact some conflict. For example one way of drawing a line between them I've heard and see used is that STATE is for transitive data that is only relevant while an instance of a program is actively running, and DATA is for anything that should persist across app runs, reboots, etc.

That's inconsistent with the explanations you posted, but either way in both cases I don't think the COTP database qualifies as state. It is a data file with stuff that may be synchronized across machines, it is not specific to one application runtime, user login session, or even computer.

from cotp.