From 5cf5b5bf42881b59525a3214995ebb4d6deded57 Mon Sep 17 00:00:00 2001
From: Lars Kruse <devel@sumpfralle.de>
Date: Sun, 20 Mar 2022 00:04:43 +0100
Subject: [PATCH] chore: fix spelling mistakes
---
.codespell-ignore-words | 1 +
README.md | 10 +++++-----
src/rest/util.py | 2 +-
src/service.py | 4 ++--
src/sync.py | 2 +-
5 files changed, 10 insertions(+), 9 deletions(-)
create mode 100644 .codespell-ignore-words
diff --git a/.codespell-ignore-words b/.codespell-ignore-words
new file mode 100644
index 0000000..9b52f09
--- /dev/null
+++ b/.codespell-ignore-words
@@ -0,0 +1 @@
+connexion
diff --git a/README.md b/README.md
index 2dc039e..cc0d7bc 100644
--- a/README.md
+++ b/README.md
@@ -67,7 +67,7 @@ acting as a reverse proxy.
### Redundant Deployment
In this scenario there are two Engine instances involved. Here you will need to deploy one Engine API on the host of each Engine instance. Additionally you'll have to set up
-a third, so-called *Syncronization Node* of the Engine API. This sync instance of Engine API is in charge of synchronizing playlogs and managing the active engine state.
+a third, so-called *Synchronization Node* of the Engine API. This sync instance of Engine API is in charge of synchronizing playlogs and managing the active engine state.
<img src="docs/engine-api_redundancy.png" />
@@ -89,8 +89,8 @@ acting as a reverse proxy to shield your API.
Usually when some new audio source starts playing, AURA Engine logs it to its local Engine API instance via some REST call. Now, the *Local API server* stores this information in its
local database. Next, it also performs a POST request to the *Synchronization API Server*. This *Sync Node* checks if this request is coming from the currently active engine instance.
-If yes, it stores this information in its playlog database. This keeps the playlogs of individual (currently active) Engine instances in sync with the *Engine API syncronization node*.
-The *Engine API syncronization node* always only stores the valid (i.e. actually played) playlog records.
+If yes, it stores this information in its playlog database. This keeps the playlogs of individual (currently active) Engine instances in sync with the *Engine API synchronization node*.
+The *Engine API synchronization node* always only stores the valid (i.e. actually played) playlog records.
##### Active Sync
@@ -103,7 +103,7 @@ obviously can not be synced. That means the local playlog at the *Engine Node* i
Such marked entries are focus of the secondary synchronization approach, the so called **Passive Sync**: Whenever the *Synchronization Node* is up- and running again, some automated job
on this node is continuously checking for records on remote nodes marked as "unsynced". If there are such records found, this indicates that there has been an outage of the *Sync Node*.
Hence those "unsynced" records are pending to be synced. Now an automated job on the *Sync Node* reads those records as batches from that Engine Node and stores them in its local database.
-It also keeps track when the last sync has happend, avoiding to query unnecceary records on any remote nodes.
+It also keeps track when the last sync has happened, avoiding to query unnecceary records on any remote nodes.
In order to avoid that this **Passive Sync** job might be causing high traffic on an engine instance, these batches are read with some configured delay time (see `sync_interval` and
`sync_step_sleep` in the *Sync Node* configuration; all values are in seconds) and a configurable batch size (`sync_batch_size`; count of max unsynced playlogs which are read at once).
@@ -243,7 +243,7 @@ To run the API in an local development server execute:
./run.sh dev
```
-This command implicitely activates the virtual environment before starting the API.
+This command implicitly activates the virtual environment before starting the API.
For convenience running a plain `./run.sh` also starts the development server.
diff --git a/src/rest/util.py b/src/rest/util.py
index ae48125..05878d3 100644
--- a/src/rest/util.py
+++ b/src/rest/util.py
@@ -24,7 +24,7 @@ def _deserialize(data, klass):
elif klass == datetime.datetime:
return deserialize_datetime(data)
- # NOTE: Due to Pyton 3.7 not providing `typing.GenericMeta` anymore,
+ # NOTE: Due to Python 3.7 not providing `typing.GenericMeta` anymore,
# this workaround is needed (See https://github.com/swagger-api/swagger-codegen/issues/8921)
# As soon this has been fixed in SwaggerHub Codegen this class can
# be replaced by the generated one again.
diff --git a/src/service.py b/src/service.py
index 7d5c4e5..04df1d3 100644
--- a/src/service.py
+++ b/src/service.py
@@ -167,7 +167,7 @@ class ApiService:
if not data.log_source:
data.log_source = self.config.get("host_id")
- # Main Node: Alway log entry, independed of the source
+ # Main Node: Always log entry, independent of the source
# Sync Node: Only log entry when it's coming from an active source
if self.node_type == NodeType.MAIN or (
self.node_type == NodeType.SYNC and data.log_source == self.active_source
@@ -347,7 +347,7 @@ class ApiService:
if not source_number:
source_number = self.host_id
- # Main Node: Alway log entry, independed of the source
+ # Main Node: Always log entry, independent of the source
# Sync Node: Only log entry when it's coming from an active source
if self.node_type == NodeType.MAIN or (
self.node_type == NodeType.SYNC and source_number == self.active_source
diff --git a/src/sync.py b/src/sync.py
index a06fa49..7dd7f4a 100644
--- a/src/sync.py
+++ b/src/sync.py
@@ -172,7 +172,7 @@ class SyncJob(threading.Thread):
"""
Create and store the next source in the ActivityLog. It's actually the same,
as the current, but acts as a references for the current sync and as a marker
- for the entrypoint of the next sync -> to avoid unneccessary sync cycles.
+ for the entrypoint of the next sync -> to avoid unnecessary sync cycles.
"""
next_source = ActivityLog(current_source.source_number)
self.Session.add(next_source)
--
GitLab