spelling fixes

services/eventhistory/README.md

@@ -1,6 +1,6 @@
 # Eventhistory
 
-The `eventhistory` consumes all events from the configured event system like NATS, stores them and allows other services to retrieve them via an eventid.
+The `eventhistory` consumes all events from the configured event system like NATS, stores them and allows other services to retrieve them via an event ID.
 
 ## Prerequisites
 
@@ -15,18 +15,18 @@ The `eventhistory` services consumes all events from the configured event system
 The `eventhistory` service stores each consumed event via the configured store in `EVENTHISTORY_STORE_TYPE`. Possible stores are:
   -   `memory`: Basic in-memory store and the default.
   -   `ocmem`: Advanced in-memory store allowing max size.
-  -   `redis`: Stores data in a configured redis cluster.
-  -   `redis-sentinel`: Stores data in a configured redis sentinel cluster.
+  -   `redis`: Stores data in a configured Redis cluster.
+  -   `redis-sentinel`: Stores data in a configured Redis Sentinel cluster.
   -   `etcd`: Stores data in a configured etcd cluster.
   -   `nats-js`: Stores data using key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store)
   -   `noop`: Stores nothing. Useful for testing. Not recommended in production environments.
 
-1.  Note that in-memory stores are by nature not reboot persistent.
-2.  Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store applies.
+1.  Note that in-memory stores are by nature not reboot-persistent.
+2.  Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store apply.
 3.  Events stay in the store for 2 weeks by default. Use `EVENTHISTORY_RECORD_EXPIRY` to adjust this value.
 4.  The eventhistory service can be scaled if not using `in-memory` stores and the stores are configured identically over all instances.
 5.  When using `redis-sentinel`, the Redis master to use is configured via `EVENTHISTORY_STORE_NODES` in the form of `<sentinel-host>:<sentinel-port>/<redis-master>` like `10.10.0.200:26379/mymaster`.
 
 ## Retrieving
 
-Other services can call the `eventhistory` service via a grpc call to retrieve events. The request must contain the eventid that should be retrieved.
+Other services can call the `eventhistory` service via a gRPC call to retrieve events. The request must contain the event ID that should be retrieved.

services/frontend/README.md

@@ -26,7 +26,7 @@ The ocs endpoint, by default `/ocs`, implements the ownCloud 10 Open Collaborati
 
 Aggregating share information is one of the most time consuming operations in OCIS. The service fetches a list of either received or created shares and has to stat every resource individually. While stats are fast, the default behavior scales linearly with the number of shares.
 
-To save network trips the sharing implementation can cache the stat requests with an in memory cache or in redis. It will shorten the response time by the network round-trip overhead at the cost of the API only eventually being updated.
+To save network trips the sharing implementation can cache the stat requests with an in memory cache or in Redis. It will shorten the response time by the network round-trip overhead at the cost of the API only eventually being updated.
 
 Setting `FRONTEND_OCS_RESOURCE_INFO_CACHE_TTL=60` would cache the stat info for 60 seconds. Increasing this value makes sense for large deployments with thousands of active users that keep the cache up to date. Low frequency usage scenarios should not expect a noticeable improvement.
 

services/gateway/README.md

@@ -13,7 +13,7 @@ The `gateway` service can use a configured store via `GATEWAY_CACHE_STORE`. Poss
   -   `nats-js`: Stores data using key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store)
   -   `noop`: Stores nothing. Useful for testing. Not recommended in production environments.
 
-1.  Note that in-memory stores are by nature not reboot persistent.
+1.  Note that in-memory stores are by nature not reboot-persistent.
 2.  Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store apply.
 3.  The gateway service can be scaled if not using `in-memory` stores and the stores are configured identically over all instances.
 4.  When using `redis-sentinel`, the Redis master to use is configured via `GATEWAY_CACHE_STORE_NODES` in the form of `<sentinel-host>:<sentinel-port>/<redis-master>` like `10.10.0.200:26379/mymaster`.

services/graph/README.md

@@ -20,14 +20,14 @@ The following image gives an overview of the scenario when a client requests to
 The `graph` service can use a configured store via `GRAPH_STORE_TYPE`. Possible stores are:
   -   `memory`: Basic in-memory store and the default.
   -   `ocmem`: Advanced in-memory store allowing max size.
-  -   `redis`: Stores data in a configured redis cluster.
-  -   `redis-sentinel`: Stores data in a configured redis sentinel cluster.
+  -   `redis`: Stores data in a configured Redis cluster.
+  -   `redis-sentinel`: Stores data in a configured Redis Sentinel cluster.
   -   `etcd`: Stores data in a configured etcd cluster.
   -   `nats-js`: Stores data using key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store)
   -   `noop`: Stores nothing. Useful for testing. Not recommended in production environments.
 
-1.  Note that in-memory stores are by nature not reboot persistent.
-2.  Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store applies.
+1.  Note that in-memory stores are by nature not reboot-persistent.
+2.  Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store apply.
 3.  The graph service can be scaled if not using `in-memory` stores and the stores are configured identically over all instances.
 4.  When using `redis-sentinel`, the Redis master to use is configured via `GRAPH_CACHE_STORE_NODES` in the form of `<sentinel-host>:<sentinel-port>/<redis-master>` like `10.10.0.200:26379/mymaster`.
 

services/ocs/README.md

@@ -7,13 +7,13 @@ The ocs service is an ...
 The `ocs` service can use a configured store via `OCS_STORE_TYPE`. Possible stores are:
   -   `memory`: Basic in-memory store and the default.
   -   `ocmem`: Advanced in-memory store allowing max size.
-  -   `redis`: Stores data in a configured redis cluster.
-  -   `redis-sentinel`: Stores data in a configured redis sentinel cluster.
+  -   `redis`: Stores data in a configured Redis cluster.
+  -   `redis-sentinel`: Stores data in a configured Redis Sentinel cluster.
   -   `etcd`: Stores data in a configured etcd cluster.
   -   `nats-js`: Stores data using key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store)
   -   `noop`: Stores nothing. Useful for testing. Not recommended in production environments.
 
-1.  Note that in-memory stores are by nature not reboot persistent.
-2.  Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store applies.
+1.  Note that in-memory stores are by nature not reboot-persistent.
+2.  Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store apply.
 3.  The ocs service can be scaled if not using `in-memory` stores and the stores are configured identically over all instances.
 4.  When using `redis-sentinel`, the Redis master to use is configured via `OCS_CACHE_STORE_NODES` in the form of `<sentinel-host>:<sentinel-port>/<redis-master>` like `10.10.0.200:26379/mymaster`.

services/proxy/README.md

@@ -98,13 +98,13 @@ In a production deployment, you want to have basic authentication (`PROXY_ENABLE
 The `proxy` service can use a configured store via `PROXY_STORE_TYPE`. Possible stores are:
   -   `memory`: Basic in-memory store and the default.
   -   `ocmem`: Advanced in-memory store allowing max size.
-  -   `redis`: Stores data in a configured redis cluster.
-  -   `redis-sentinel`: Stores data in a configured redis sentinel cluster.
+  -   `redis`: Stores data in a configured Redis cluster.
+  -   `redis-sentinel`: Stores data in a configured Redis Sentinel cluster.
   -   `etcd`: Stores data in a configured etcd cluster.
   -   `nats-js`: Stores data using key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store)
   -   `noop`: Stores nothing. Useful for testing. Not recommended in production environments.
 
-1.  Note that in-memory stores are by nature not reboot persistent.
-2.  Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store applies.
+1.  Note that in-memory stores are by nature not reboot-persistent.
+2.  Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store apply.
 3.  The proxy service can be scaled if not using `in-memory` stores and the stores are configured identically over all instances.
 4.  When using `redis-sentinel`, the Redis master to use is configured via `PROXY_OIDC_USERINFO_CACHE_NODES` in the form of `<sentinel-host>:<sentinel-port>/<redis-master>` like `10.10.0.200:26379/mymaster`.

services/storage-system/README.md

@@ -12,7 +12,7 @@ The `storage-system` service caches file metadata via the configured store in `S
   -   `nats-js`: Stores metadata using the key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store)
   -   `noop`: Stores nothing. Useful for testing. Not recommended in production environments.
 
-1.  Note that in-memory stores are by nature not reboot persistent.
-2.  Though usually not necessary, a database name can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`, `redis` and `redis-sentinel`. These settings are blank by default which means that the standard settings of the configured store applies.
+1.  Note that in-memory stores are by nature not reboot-persistent.
+2.  Though usually not necessary, a database name can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`, `redis` and `redis-sentinel`. These settings are blank by default which means that the standard settings of the configured store apply.
 3.  The `storage-system` service can be scaled if not using `in-memory` stores and the stores are configured identically over all instances.
 4.  When using `redis-sentinel`, the Redis master to use is configured via `STORAGE_SYSTEM_CACHE_NODES` in the form of `<sentinel-host>:<sentinel-port>/<redis-master>` like `10.10.0.200:26379/mymaster`.

services/storage-users/README.md

@@ -91,7 +91,7 @@ The `storage-users` service caches stat and metadata via the configured store in
   -   `nats-js`: Stores metadata using the key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store)
   -   `noop`: Stores nothing. Useful for testing. Not recommended in production environments.
 
-1.  Note that in-memory stores are by nature not reboot persistent.
+1.  Note that in-memory stores are by nature not reboot-persistent.
 2.  Though usually not necessary, a database name can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`, `redis` and `redis-sentinel`. These settings are blank by default which means that the standard settings of the configured store apply.
 3.  The `storage-users` service can be scaled if not using `in-memory` stores and the stores are configured identically over all instances.
 4.  When using `redis-sentinel`, the Redis master to use is configured via `STORAGE_USERS_STAT_CACHE_STORE_NODES` and `STORAGE_USERS_FILEMETADATA_CACHE_STORE_NODES` in the form of `<sentinel-host>:<sentinel-port>/<redis-master>` like `10.10.0.200:26379/mymaster`.

services/userlog/README.md

@@ -11,14 +11,14 @@ Running the `userlog` service without running the `eventhistory` service is not
 The `userlog` service persists information via the configured store in `USERLOG_STORE_TYPE`. Possible stores are:
   -   `memory`: Basic in-memory store and the default.
   -   `ocmem`: Advanced in-memory store allowing max size.
-  -   `redis`: Stores data in a configured redis cluster.
-  -   `redis-sentinel`: Stores data in a configured redis sentinel cluster.
+  -   `redis`: Stores data in a configured Redis cluster.
+  -   `redis-sentinel`: Stores data in a configured Redis Sentinel cluster.
   -   `etcd`: Stores data in a configured etcd cluster.
   -   `nats-js`: Stores data using key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store)
   -   `noop`: Stores nothing. Useful for testing. Not recommended in production environments.
 
-1.  Note that in-memory stores are by nature not reboot persistent.
-2.  Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store applies.
+1.  Note that in-memory stores are by nature not reboot-persistent.
+2.  Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store apply.
 3.  The userlog service can be scaled if not using `in-memory` stores and the stores are configured identically over all instances.
 4.  When using `redis-sentinel`, the Redis master to use is configured via `USERLOG_STORE_NODES` in the form of `<sentinel-host>:<sentinel-port>/<redis-master>` like `10.10.0.200:26379/mymaster`.