Discussion about file format for the future

Hi,

rdiff-backup has currently its own file formats, which are far from
being standard, meaning a lot of custom code to handle these formats,
respectively a lot of different files.

Middle term I'd like to move to a more standard format for code
efficiency reasons: if the code is in a library, I don't need to write
and maintain it, and newcomers don't need to learn the format.

My opinion is almost made on which format I'd like to use but I want to
make sure I don't miss arguments and hence open the discussion before
it's too late.

On the basis that we have 4 potential formats to consider (XML, JSON,
YAML or TOML), I've put together the following criteria:

- human readable, standardized, well-maintained Python library
available, the obvious... (all)
- allows for comments, useful for debugging and testing purposes (JSON out)
- as little verbose as possible, easy to create/fix manually (XML out,
JSON ok-ish)
- complete language, i.e. allows for dicts, lists, lists of dicts, etc.,
up to a full-blown serialization language [1] (TOML out)
- streamable, i.e. doesn't need a closing element to be valid, because
our current formats are like this, and it fits better the
iterable-approach used throughout the code (JSON and XML out)

I was almost finished with this list, as I discovered [2] which in many
more words and examples are saying quite the same.

Side note: even if the arguments are good, I'm not planning to use
strictyaml, a library not even packaged for Fedora. I'd prefer to use
the safe_load function of pyyaml, or whatever fits the needs (YAML 1.2
[4] might even get support in the near future [5]).

As written, my point is about simplifying the code, no immediate
decision required, but I prefer to have this discussion before it's too
late to have it...

Thanks, Eric

[1] https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats
[2] https://hitchdev.com/strictyaml/why-not/
[3] https://pyyaml.org/
[4] https://yaml.org/spec/1.2/spec.html
[5] https://github.com/yaml/pyyaml/issues/116