Closed rpdelaney closed 8 months ago
There is also DHTnodes.json
, the functionality of which I am no completely sure on. It should either go into the new XDG_STATE_HOME
or into CACHE
, depending on whether it captures any relevant state. Seems a good fit for STATE at first glance.
XDG_STATE_HOME
Oh my god. They finally did this. I'm so happy.
Closing due to inactivity. It works fine the way it is and it's not worth my time to maintain a bunch of backwards compatible code. As far as "dangerous deviations" go, people are responsible for their own data. There's no reason in this day and age for anyone to be backing up anything without encryption, much less without even knowing the contents of said data.
Edit: With that said, if someone else wants to write the code and do a seamless transition without breaking anything, I'll gladly accept the PR.
if someone else wants to write the code and do a seamless transition without breaking anything, I'll gladly accept the PR.
That's all I needed to hear, thanks! :) I'll add it to my personal backlog.
In general toxic does support the XDG directory specification, but support is not completely implemented. Critically, toxic provides no options that I'm aware of to divide configuration data from state data.
For emphasis, users who do not expect state data to be stored here may accidentally back it up and synchronize it across systems improperly. Configuration data are fine, but prefer storing state data somewhere in
$XDG_DATA_HOME
to conform to the freedesktop.org / XDG standard.Reference: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html