Most services allow the user to keep configuration and data/state/cache separate (eg. /etc vs /var, ~/.config vs ~/.local/share/~/.cache).
This makes possible a bunch of stuff like:
different backup strategies for config and data
making the configuration read-only
easily cleaning the state while keeping the configuration
Some files used by fedigroups are fixed (config.json, groups.json..) and some are mutable (control.json, state.json..).
It'd be nice if fedigroups had a --data option in addition to --config, with which one could specify where the mutable state should go.
Most services allow the user to keep configuration and data/state/cache separate (eg. `/etc` vs `/var`, `~/.config` vs `~/.local/share`/`~/.cache`).
This makes possible a bunch of stuff like:
* different backup strategies for config and data
* making the configuration read-only
* easily cleaning the state while keeping the configuration
Some files used by fedigroups are fixed (`config.json`, `groups.json`..) and some are mutable (`control.json`, `state.json`..).
It'd be nice if fedigroups had a `--data` option in addition to `--config`, with which one could specify where the mutable state should go.
Have you seen the way it worked before? Everything was in one big JSON file that was constantly overwritten. Kind of scary. The way its split now is much better imo.
This is quite a big change and I dont personally want it, but if you add it, I'll probably accept the MR.
The data directory would have to mirror the structure of the current groups directory, so by default nothing changes, but you can tell it to put data elsewhere if you opt in. It shouldn't be too difficult to add.
Things to consider though:
the only really immutable files are groups.json and config.json in the group folders, except the latter actually is mutable in case of authing a new group or re-authing using -A. You can chmod it afterwards, of course.
control.json contains the member list, group tags etc. This file is mutated by the group actor when you tell it to using a slash command, when a user joins, etc. You don't want to lose it. It's separated from config.json so you can make config.json with the auth keys read-only.
state.json also should be backed up, unless you disable the notification catch-up feature, then it doesn't matter. This file is separated because it's overwritten very often.
Have you seen the way it worked *before*? Everything was in one big JSON file that was constantly overwritten. Kind of scary. The way its split now is much better imo.
This is quite a big change and I dont personally want it, but if you add it, I'll probably accept the MR.
The data directory would have to mirror the structure of the current groups directory, so by default nothing changes, but you can tell it to put data elsewhere if you opt in. It shouldn't be too difficult to add.
Things to consider though:
- the only really immutable files are `groups.json` and `config.json` in the group folders, except the latter actually is mutable in case of authing a new group or re-authing using `-A`. You can chmod it afterwards, of course.
- `control.json` contains the member list, group tags etc. This file is mutated by the group actor when you tell it to using a slash command, when a user joins, etc. You don't want to lose it. It's separated from `config.json` so you can make `config.json` with the auth keys read-only.
- `state.json` also should be backed up, unless you disable the notification catch-up feature, then it doesn't matter. This file is separated because it's overwritten very often.
Have you seen the way it worked before? Everything was in one big JSON file that was constantly overwritten. Kind of scary. The way its split now is much better imo.
I did not and yes, it sounds much better now
The data directory would have to mirror the structure of the current groups directory, so by default nothing changes, but you can tell it to put data elsewhere if you opt in.
what should happen if the user specifies --config but not --data? Should --data default to what is specified in --config or to the working directory?
you listed some config files and some data files. are there any cache files that can be removed without loss of data?
> Have you seen the way it worked before? Everything was in one big JSON file that was constantly overwritten. Kind of scary. The way its split now is much better imo.
I did not and yes, it sounds much better now
> The data directory would have to mirror the structure of the current groups directory, so by default nothing changes, but you can tell it to put data elsewhere if you opt in.
what should happen if the user specifies `--config` but not `--data`? Should `--data` default to what is specified in `--config` or to the working directory?
you listed some config files and some data files. are there any cache files that can be removed without loss of data?
I believe `--config` tells it where `groups.json` is, the `groups` and `locales` folders are then found relative to this file.
There's no cache files, that's why I'm kind of skeptical about this change.
I imagine it could work something like this:
`/etc/fedigroups/`
```
├── groups
│ ├── betty@piggo.space
│ │ └── config.json
│ └── chatterbox@botsin.space
│ ├── messages.json
│ └── config.json
├── locales
│ └── ru.json
└── groups.json
```
Notice how `groups.json` contains these:
```
// name of the directory with groups
"groups_dir": "groups",
// name of the directory with locales
"locales_dir": "locales",
```
So the data directory could be another entry, defaulting to "groups". But if you choose to split it, it will look like this:
`/var/fedigroups/`
```
├── betty@piggo.space
│ ├── control.json
│ └── state.json
└── chatterbox@botsin.space
├── control.json
└── state.json
```
I see, thank you for the clarification. I missed the *_dir fields.
That actually makes this change useless as long as one considers config.json as data and if those fields can contain absolute paths.
I'll think about it.
I see, thank you for the clarification. I missed the *_dir fields.
That actually makes this change useless as long as one considers config.json as data and if those fields can contain absolute paths.
I'll think about it.
Most services allow the user to keep configuration and data/state/cache separate (eg.
/etc
vs/var
,~/.config
vs~/.local/share
/~/.cache
).This makes possible a bunch of stuff like:
Some files used by fedigroups are fixed (
config.json
,groups.json
..) and some are mutable (control.json
,state.json
..).It'd be nice if fedigroups had a
--data
option in addition to--config
, with which one could specify where the mutable state should go.Have you seen the way it worked before? Everything was in one big JSON file that was constantly overwritten. Kind of scary. The way its split now is much better imo.
This is quite a big change and I dont personally want it, but if you add it, I'll probably accept the MR.
The data directory would have to mirror the structure of the current groups directory, so by default nothing changes, but you can tell it to put data elsewhere if you opt in. It shouldn't be too difficult to add.
Things to consider though:
groups.json
andconfig.json
in the group folders, except the latter actually is mutable in case of authing a new group or re-authing using-A
. You can chmod it afterwards, of course.control.json
contains the member list, group tags etc. This file is mutated by the group actor when you tell it to using a slash command, when a user joins, etc. You don't want to lose it. It's separated fromconfig.json
so you can makeconfig.json
with the auth keys read-only.state.json
also should be backed up, unless you disable the notification catch-up feature, then it doesn't matter. This file is separated because it's overwritten very often.I did not and yes, it sounds much better now
what should happen if the user specifies
--config
but not--data
? Should--data
default to what is specified in--config
or to the working directory?you listed some config files and some data files. are there any cache files that can be removed without loss of data?
I believe
--config
tells it wheregroups.json
is, thegroups
andlocales
folders are then found relative to this file.There's no cache files, that's why I'm kind of skeptical about this change.
I imagine it could work something like this:
/etc/fedigroups/
Notice how
groups.json
contains these:So the data directory could be another entry, defaulting to "groups". But if you choose to split it, it will look like this:
/var/fedigroups/
I see, thank you for the clarification. I missed the *_dir fields.
That actually makes this change useless as long as one considers config.json as data and if those fields can contain absolute paths.
I'll think about it.