Use semantic line breaks in README

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

View file

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

View file

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