More ADR stuff.

Signed-off-by: Cliff Hill <xlorep@darkhelm.org>

docs/adrs/001-async.md

@@ -1,19 +0,0 @@
-# ADR 001: Implement as asynchronous application
-
-Due to the multiple paths and processes that need to be run to gather and collect data over a network and the lack of need to synchronously process anything, it is found to be necessary to run the application in an asynchrounous manner,
-
-## Decision
-
-The application will be written using an asynchronous design. Selection of other libraries to use for the application will be focused on asynchronous libraries whenever possible. If no asynchronous library is possible/available, the use of threadpools and processpools will be determined on a case-by-case manner.
-
-## Rationale
-
-It makes more sense to build the application from the ground up as asynchronous rather than synchronous first and later asynchronous, as there will be less tech debt to make a decision like this up-front.
-
-## Status
-
-Accepted
-
-## Consequences
-
-There will likely be complications as expected from any concurrency operations which will need to be dealt with when they arise.

docs/adrs/001-concurrency.md

@@ -0,0 +1,26 @@
+# ADR 001: Pick a good concurrency solution
+
+The application has several components that would benefit from concurrency. The four options looked at are:
+
+1. Synchronous - no concurrency at all, everything in a single thread, executed in sequence.
+2. Threading - OS threading concurrency, with the GIL limiting to a single thread being able to use the processor at one time.
+3. Multiprocessing - Independent full Python processes, usually pointlessly expensive beyond the number of cores the system has.
+4. Asynchronous - Single-thread, but with cooperative concurrency allowing typically for processes to be able to wait for something, like I/O easily.
+
+## Decision
+
+The application will be written using an asynchronous design. Selection of other libraries to use for the application will be focused on asynchronous libraries whenever possible. If no asynchronous library is possible/available, the use of threadpools and processpools will be determined on a case-by-case manner.
+
+## Rationale
+
+The best approach would be to use async, as this gives the most flexibility. With the use of ThreadPools and ProcessPools, it can allow for synchronous/blocking code to become non-blocking with threads/processes dividing up the work. It does not have the limitations that could be imposed on threading or multiprocessing, and there is wide-spred acceptance of async in Python now.
+
+It is better to choose async up-front, as the conversion from sync to async is a major burden, it is easier to start with it from the start.
+
+## Status
+
+Accepted
+
+## Consequences
+
+There will likely be complications as expected from any concurrency operations which will need to be dealt with when they arise. It is important to write as much code using coroutines as possible to avoid blocking issues, and to remember to `await` them when calling them.

docs/adrs/002-configuration-file-format.md

@@ -1,4 +1,4 @@
-# ADR 002: TOML
+# ADR 002: Choose a good configuration file format.
 
 A good configuration file format needs to be selected. There are three main choices that were considered:
 

docs/adrs/003-configuration-file-location.md

@@ -0,0 +1,22 @@
+# ADR 003: Choose location of configuration and other files
+
+It is important to store files in a way that is appropriate for whatever platform the application is running on, as such there is a library that can handle this correctly and efficiently. Two different libraries were reviewed:
+
+1. `appdirs` - sets up directories which can be written to easily, in a synchronous manner.
+2. `app-paths` - does what `appdirs` does, but with `Path` objects (or `AsyncPath`), and allows for async file operations.
+
+## Decision
+
+`app-paths` was chosen.
+
+## Rationale
+
+Using the library `app-paths` allows for the different paths needed for configuration, logs, etc to be defined in such a way as to be platform-agnostic, and will automatically make the paths be put in an appropriate location for the system that the application is running on. The fact that it allows for files to be operated on asynchronously and using an AsyncPath object makes it an obvious choice for this application.
+
+## Status
+
+Accepted
+
+## Consequences
+
+Not exactly certain what concequences there will be with this choice. It seems the better choice all around.