mrtoth/thesis
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

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

Browse Source
This commit is contained in:
Kristóf Tóth 2018-12-05 22:44:38 +01:00
parent 2420ab3bfd
commit 23612c6151
2 changed files with 45 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
content/architecture.tex
View File

@ -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}

39
content/summary.tex
View File

@ -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