Conor425/ludusavi-manifest
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Use semantic line breaks in README

Browse source
This commit is contained in:
mtkennerly 2023-12-09 16:31:12 +08:00
parent 11e9228262
commit 781983fbcd
No known key found for this signature in database
GPG key ID: E764BE00BE6E6408
2 changed files with 37 additions and 39 deletions
Download patch file Download diff file Expand all files Collapse all files

13
CONTRIBUTING.md
View file

@ -23,14 +23,15 @@ There are some lower-level commands for finer control or full imports:
* `cargo run -- schema`
## API etiquette
When running or modifying the importer script, please be mindful not to
unnecessarily spam the PCGW or Steam APIs.
When running or modifying the importer script,
please be mindful not to unnecessarily spam the PCGW or Steam APIs.
The [Mediawiki guidelines](https://www.mediawiki.org/wiki/API:Etiquette)
suggest that:
> Making your requests in series rather than in parallel, by waiting for one request
> to finish before sending a new request, should result in a safe request rate.
> Making your requests in series rather than in parallel,
> by waiting for one request to finish before sending a new request,
> should result in a safe request rate.
I am not sure about guidelines for the Steam API, but the cache file should mean
that we are not making excessive requests.
I am not sure about guidelines for the Steam API,
but the cache file should mean that we are not making excessive requests.

63
README.md
View file

@ -1,27 +1,27 @@
# Ludusavi Manifest
The Ludusavi Manifest format is a YAML structure for defining the location of
game save data and other files that are of interest to back up. Although this
project was started for use by [Ludusavi](https://github.com/mtkennerly/ludusavi),
the goal is for the manifest format to be generic enough for any game backup tool
to implement, while leaving room for new fields and functionality over time.
The Ludusavi Manifest format is a YAML structure for defining
the location of game save data and other files that are of interest to back up.
Although this project was started for use by [Ludusavi](https://github.com/mtkennerly/ludusavi),
the goal is for the manifest format to be generic enough for any game backup tool to implement,
while leaving room for new fields and functionality over time.
This repository contains the [primary manifest](data/manifest.yaml), which is
compiled from data on [PCGamingWiki](https://www.pcgamingwiki.com/wiki/Home),
This repository contains the [primary manifest](data/manifest.yaml),
which is compiled from data on [PCGamingWiki](https://www.pcgamingwiki.com/wiki/Home),
along with accessing the Steam API for game installation directory names.
If you find any data that is missing or incorrect, please contribute to the wiki,
and such changes will be incorporated into the primary manifest periodically.
There is also a list of [games without any info on what to back up](data/missing.md).
Game developers may include a secondary manifest (named `.ludusavi.yaml`) with
their games, so that backup tools can automatically detect and use it to discover
what files need to be backed up for save data and configuration.
Game developers may include a secondary manifest (named `.ludusavi.yaml`) with their games,
so that backup tools can automatically detect and use it
to discover what files need to be backed up for save data and configuration.
## Format
For the schema, refer to [schema.yaml](data/schema.yaml). Note that the primary
manifest is validated with [schema.strict.yaml](data/schema.strict.yaml), which
additionally specifies enums for some fields. However, tools should implement
[schema.yaml](data/schema.yaml), so that new values in the manifest do not break
older tools.
For the schema, refer to [schema.yaml](data/schema.yaml).
Note that the primary manifest is validated with [schema.strict.yaml](data/schema.strict.yaml),
which additionally specifies enums for some fields.
However, tools should implement [schema.yaml](data/schema.yaml),
so that new values in the manifest do not break older tools.
Here is an example:
@ -57,8 +57,7 @@ This means:
* `<base>/saves` will be backed up on any system.
* `<base>/settings.json` will be backed up if you're using Windows or Linux.
* `<base>/other` will be backed up if you're using Mac and Steam.
* On Windows, the registry key `HKEY_CURRENT_USER/Software/An Example Game` will be
backed up.
* On Windows, the registry key `HKEY_CURRENT_USER/Software/An Example Game` will be backed up.
Paths in the `files` section can include these placeholders:
@ -83,10 +82,9 @@ Paths in the `files` section can include these placeholders:
Tools must implement the following in addition to respecting the schema:
* For paths, first substitute the placeholders, then evaluate as a glob.
Because of treating paths as globs, a path may match multiple files or
directories.
* When a path identifies a folder, the backup includes all of its files
and subdirectories recursively.
Because of treating paths as globs, a path may match multiple files or directories.
* When a path identifies a folder,
the backup includes all of its files and subdirectories recursively.
* When backing up registry keys, the backup includes all sub-keys recursively.
* Relative paths must be resolved relative to the location of the manifest file.
This is mainly relevant for secondary manifests.
@ -96,16 +94,16 @@ Tools must implement the following in addition to respecting the schema:
Tools may also:
* Use store-specific logic to determine the `<base>`. For example,
with Steam, if the root is `~/.steam/steam`, then `<base>` would be
`<root>/steamapps/common/<game>`. Or a tool could use `<root>/**/<game>`
as a generic option, although it could lead to wasted search time.
* Check possible save data locations even if the entry has inapplicable
constraints. For example, if a file entry is marked as `os: windows`, then
ideally a tool should only need to check that entry when running on Windows;
however, it is a reality of the data set that it may simply be the only
confirmed occurrence of the file, and it may in fact occur on other operating
systems as well.
* Use store-specific logic to determine the `<base>`.
For example, with Steam, if the root is `~/.steam/steam`,
then `<base>` would be `<root>/steamapps/common/<game>`.
Or a tool could use `<root>/**/<game>` as a generic option,
although it could lead to wasted search time.
* Check possible save data locations even if the entry has inapplicable constraints.
For example, if a file entry is marked as `os: windows`,
then ideally a tool should only need to check that entry when running on Windows;
however, it is a reality of the data set that it may simply be the only confirmed occurrence of the file,
and it may in fact occur on other operating systems as well.
For authors of secondary manifests bundled with games:
@ -121,8 +119,7 @@ https://raw.githubusercontent.com/mtkennerly/ludusavi-manifest/master/data/manif
To check for updates:
* Store the value of the `ETag` header for the last downloaded version.
* Send a GET request to the URL with the `If-None-Match` header set to the
last known `ETag` value.
* Send a GET request to the URL with the `If-None-Match` header set to the last known `ETag` value.
* If the response code is 304, then no update is needed.
* If the response code is 200, then store the new `ETag` value.