QUICKSTART: typo and math fix (h/t @etam@im-in.space)

merge-requests/23/head
Michał 'rysiek' Woźniak 2022-03-10 10:17:39 +00:00
rodzic 17b0450e76
commit c3635371d1
1 zmienionych plików z 2 dodań i 2 usunięć

Wyświetl plik

@ -141,7 +141,7 @@ Our `config.json` should now look like this:
Note the addition of the `cache` plugin config, and a "cache" component in `loggedComponents`. The `cache` plugin does not require any other configuration to work, so everything remains nice and simple.
You will also note the additional key in the config file: `defaultPluginTimeout`. This defines how long (in ms; `1000` there means "2 seconds") does LibResilient wait for a response from a plugin before it decides that it is not going to work, and moves on to the next plugin. By default this is set to `10000` (so, 10s), which is almost certainly too long for a website as simple as in our example. One second seems reasonable.
You will also note the additional key in the config file: `defaultPluginTimeout`. This defines how long (in ms; `1000` there means "1 second") does LibResilient wait for a response from a plugin before it decides that it is not going to work, and moves on to the next plugin. By default this is set to `10000` (so, 10s), which is almost certainly too long for a website as simple as in our example. One second seems reasonable.
What this gives us is that any content successfully retrieved by `fetch` will now be cached for offline use. If the website goes down for whatever reason (and the `fetch` plugin starts returning errors or just times out), users who had visited before will continue to have access to content they had already accessed.