Add the main file, with the majority of the documentation.

main.cpp

@@ -0,0 +1,108 @@
+#include <iostream>
+#include <string>
+using namespace std;
+
+/* Team Kitty, 2019 */
+/*   Guinevere One  */
+
+/* This package is the parsing system (NLP) for the Guinevere system.
+    This package is split up into 5 different parts, each controlled by
+    modules. This is the file that controls all of the other modules,
+    making sure that the system reacts the way it was configured.
+
+   It should be mentioned here, before we start, that this system does
+    not use advanced Machine Learning systems, or anything automagical.
+    It runs entirely on predetermined algorithms, which are fully
+    designed manually, so the system is not infallible.
+
+   The system can be configured to run in 3 different ways;
+  - As a console application, where it uses stdio to communicate with
+    the user, parsing internally. This is ideal for command-line usage,
+    and was designed purely for testing the system. This is not the
+    intended usage.
+  - As a web server. In this configuration, it starts a web server on a
+    configurable port and listens for incoming connections. This is the
+    intended usage of the Guinevere parsing system, as it can then send
+    out commands to other devices.
+  - As a web client. In this configuration it listens for input over
+    stdin and sends it out to the listen server. This makes developing
+    the main clients considerably faster.
+        Maybe implement this into the Guinevere main clients eventually?
+
+   Currently, the program has 5 sections, as mentioned above:
+  - Input; this is where the 3 modes mentioned above are implemented
+  - Parsing; this is only done if the console app configuration is
+    chosen above. Otherwise, it skips this module.
+  - Evaluation; this is only done in debug mode, in console app
+    configuration. It tries to prepare an output that tells the user how
+    likely it was to pick each module for the given input.
+  - Knowledge; if the output was strange, and if "Define" was the most
+    likely module in Evaluation, it can save time by enabling the
+    Knowledge system to attempt to get a definition of the "Define"
+    keyword from Wolfram|Alpha. Since this cuts down the rate of network
+    access by half, it might improve data usage.
+  - Output; finally, once all of the sections have yielded, it tries
+    to output the requested data in a decent format. If the system is
+    running as a console app, it outputs to STDOUT. If the system is
+    running as a web server, it sends a nicely formatted JSON
+    encoded package to the connected client, or displays said package if
+    running as the client.
+
+   The Parsing and Knowledge systems connect to various Modules:
+  - Identify: Triggered by "What is", "Who is" and "How do I" questions.
+    It tries to pull a short definition from WikiTL;DR, or redirects to
+    the most appropriate Wiki page if that fails. If the user complains,
+    saying "That wasn't useful", or "Try again", it tries to reach out
+    to Plowie or W|A to get an answer there. If Identify doesn't work,
+    it falls through to the next appropriate module.
+        This is the module expected to be used the most, so it will have
+        the most time put into it.
+  - Control: Triggered by "Set", "Play" or other commands that are
+    deemed to be likely to control or change the state of something.
+    The Guinevere system was originally designed to be used with
+    custom Smart Home electronics and systems, so this will probably
+    be the second most developed system. It will have subsystems for
+    changing the color and intensity of smart lighting, as well as
+    systems for controlling custom Smart Locks eventually.
+    This will not be forseeable for quite a while, though.
+  - System Control: A subsystem of Control, but important enough to
+    require an explanation nonetheless. If Guinevere is eventually
+    integrated within Sync, this module will allow voice control of many
+    internal components of the system. With a builtin passcode, it can
+    also be used to control kernel level things, like multitasking
+    methods and paging control systems. In user-land, it can also be
+    used for dictation input (if you trust my algorithms enough)
+    or for changing user settings, such as keyboard layout, hotkey
+    behaviour, or window manager/compositor settings.
+        Perhaps this interface could eventually be used as an
+        optional replacement for configuration files?
+  - Define: The fallthrough. If the user says a random word, which is
+    not identified as a custom keyword, then the system will ping W|A to
+    get a nicely formatted definition of that word.
+*/
+
+// First is the definition of the common types:
+/* There are three main classes used in the processing of requests:
+  - First, there is the input. The input is returned by the input
+    detection system, and is used in Processing for determining the
+    Intent.
+  - Second, there is the Intent itself. The Intent is a construction
+    of how likely the input command is to belong to a module. Since
+    the Intent algorithm is an algorithm and not a Machine Learning/
+    Neural Network thing, it can be easily changed and tweaked to match
+    the correct criteria. Out of the Processing system, the intent is
+    used to trigger the correct module and the Intent is then discarded.
+  - The output is a structure which is given from Processing to Output,
+    and is used to generate a nicely formatted output. The output itself
+    is sent around inside the program as a JSON/XML string. I have yet
+    to decide.
+*/
+
+
+int main() {
+    
+
+    return 0;
+}
+
+