Remove company secrets ¯\_(ツ)_/¯

content/architecture.tex

@@ -1,4 +1,12 @@
 \chapter{Framework Architecture}\label{architecture}
+
+This chapter discusses the design of the framework and the technological details
+behind its architecture.
+First, I am going to explain what the purpose of this architecture is and what
+the functions it aims to provide are,
+then I'll clarify what technologies are used --- and how --- to satisfy and implement said
+functionality.
+
 \section{Core Technology}
 
 It is important to understand that the Tutorial Framework is currently implemented as
@@ -114,10 +122,12 @@ that seem to occur randomly.},
     force you to write synchronous or asynchronous code, whereas common HTTP servers
     are either async%
 \footnote{Async servers use the \code{select} or \code{epoll} system calls among others
-to avoid blocking on IO.} or pre-fork%
+to avoid blocking on IO and handle concurrent requets.} or thread-per-connection%
-\footnote{Pre-fork servers spawn multiple processes and threads to handle requests
+\footnote{Thread-per-connection servers spawn multiple processes and threads to handle requests
 simultaneously.} in nature, which extorts certain design choices on code
-    built on them.
+    built on them%
+\footnote{Writing async code forces you to avoid blocking calls, whereas with threads you have to
+watch out for common multithreading problems, like race conditions or deadlocks}.
 \end{itemize}
 
 \section{Architectural Overview}

content/summary.tex

@@ -34,14 +34,39 @@ we are just getting started.
 \section{I Have a Plan!}
 
 In this section I'd like to set some goals regarding the future of the framework
-apart from implementing new features, as these will always keep coming in, and we
+\emph{apart} from implementing new features.
-have some great ones planned, that I can promise.
+Features are important, of course, but they will always keep coming in, no
+matter what we do and I have no fears: our roadmap is filled with awesome new
+ideas.
+Instead, what I'd like to focus on is areas that need improvement,
+and some of the plans I have regarding these areas.
 
-First of all I think that we need to put more focus on developing TFW, as currently
+A very important thing that currently needs improving is language support.
-other projects are often being prioritized over it.
+While it is very easy to implement event handlers on arbitrary languages,
-While some of these are understandable, the framework is a very promising project
+there are some things which are only convenient to do from Python.
-with great potential and deserves more attention from us.
+The remedy here would be exposing all Python-specific functionality on TFW message APIs
-The fact that it is stable does not validate neglecting it.
+as well, which should only take a few days of work for me to do.
+
+Another issue is that some developers, who might have no experience in dealing
+with low-level socket logic could find working with ZeroMQ somewhat frightening%
+\footnote{Despite ZMQ is actually a lot easier to work with than raw TCP sockets}.
+This is only problematic if there is no event handler library code for
+their chosen languages of course.
+A new idea I have been playing around with is somehow allowing developers to use
+named pipes\footnote{\href{http://man7.org/linux/man-pages/man7/pipe.7.html}
+{http://man7.org/linux/man-pages/man7/pipe.7.html}}
+to implement event handlers, as working with these is similar to reading and writing
+to simple files, a concept every developer is familiar with.
+A similar idea is to allow registering simple shell commands as event handlers, with
+the received message as a command line argument:
+there are lot's of cases when developers don't want to keep listening for more
+messages to handle, they just want a ``fire and forget'' type of approach.
+
+Built-in event handlers could also have a config file like frontend components have
+with \code{config.ts}.
+This would allow developers to set them up without having to deal with additional
+Python code, and would allow me greater freedom in implementing them, as I
+wouldn't have to keep developers without Python knowledge in mind when working on these.
 
 I'd also like to concentrate on stabilizing the API of the framework.
 Currently each major release lasts for a few months before I am forced to break something