diff --git a/content/architecture.tex b/content/architecture.tex
index 8d0312b..ab73a45 100644
--- a/content/architecture.tex
+++ b/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%
-\footnote{Pre-fork servers spawn multiple processes and threads to handle requests
+to avoid blocking on IO and handle concurrent requets.} or thread-per-connection%
+\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}
diff --git a/content/summary.tex b/content/summary.tex
index ed17322..31424ac 100644
--- a/content/summary.tex
+++ b/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
-have some great ones planned, that I can promise.
+\emph{apart} from implementing new features.
+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
-other projects are often being prioritized over it.
-While some of these are understandable, the framework is a very promising project
-with great potential and deserves more attention from us.
-The fact that it is stable does not validate neglecting it.
+A very important thing that currently needs improving is language support.
+While it is very easy to implement event handlers on arbitrary languages,
+there are some things which are only convenient to do from Python.
+The remedy here would be exposing all Python-specific functionality on TFW message APIs
+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