Reorder, will fill later

Rewritten-docs.md

@@ -712,13 +712,52 @@ This discussion is a never ending story which is done through the whole
 development process. Some of the most important implementation problems or
 interesting observations will be discussed in this chapter.
 
-### Backend communication
+### General communication
 
 @todo: what type of communication within backend could be used, mention some
 frameworks, queue managers, protocols, which was considered - why we don't use
 CORBA, RabbitMQ and why is ZeroMQ great
 
-@todo: maybe merge frontend communication into this
+Frontend communication follows the choice, that ReCodEx should be primary a web
+application. The communication protocol has to reflect client-server
+architecture. There are several options:
+
+- *TCP sockets* -- TCP sockets give a reliable means of a full-duplex
+  communication. All major operating systems support this protocol and there are
+  libraries which simplify the implementation.  On the other side, it is not
+  possible to initiate a TCP socket from a web browser.
+- *WebSockets* -- The WebSocket standard is built on top of TCP. It enables a
+  web browser to connect to a server over a TCP socket. WebSockets are
+  implemented in recent versions of all modern web browsers and there are
+  libraries for several programming languages like Python or JavaScript (running
+  in Node.js).  Encryption of the communication over a WebSocket is supported as
+  a standard.
+- *HTTP protocol* -- The HTTP protocol is a state-less protocol implemented on
+  top of the TCP protocol.  The communication between the client and server
+  consists of a requests sent by the client and responses to these requests sent
+  back by the sever. The client can send as many requests as needed and it may
+  ignore the responses from the server, but the server must respond only to the
+  requests of the client and it cannot initiate communication on its own.
+  End-to-end encryption can be achieved easily using SSL (HTTPS).
+
+We chose the HTTP(S) protocol because of the simple implementation in all sorts
+of operating systems and runtime environments on both the client and the server
+side.
+
+The API of the server should expose basic CRUD (Create, Read, Update, Delete)
+operations. There are some options on what kind of messages to send over the
+HTTP:
+
+- SOAP -- a protocol for exchanging XML messages. It is very robust and complex.
+- REST -- is a stateless architecture style, not a protocol or a technology. It
+  relies on HTTP (but not necessarily) and its method verbs (e.g., GET, POST,
+  PUT, DELETE). It can fully implement the CRUD operations.
+
+Even though there are some other technologies we chose the REST style over the
+HTTP protocol. It is widely used, there are many tools available for development
+and testing, and it is understood by programmers so it should be easy for a new
+developer with some experience in client-side applications to get to know with
+the ReCodEx API and develop a client application.
 
 ### Broker
 
@@ -1041,49 +1080,6 @@ the monitor. To solve this, messages for each job are hold 5 minutes after
 reception of last message. The client gets all already received messages at time
 of connection with no message loss.
 
-
-### Frontend communication
-
-The first thing we need to address is the communication protocol of this
-client-server architecture. There are several options:
-
-- *TCP sockets* -- TCP sockets give a reliable means of a full-duplex
-  communication. All major operating systems support this protocol and there are
-  libraries which simplify the implementation.  On the other side, it is not
-  possible to initiate a TCP socket from a web browser.
-- *WebSockets* -- The WebSocket standard is built on top of TCP. It enables a
-  web browser to connect to a server over a TCP socket. WebSockets are
-  implemented in recent versions of all modern web browsers and there are
-  libraries for several programming languages like Python or JavaScript (running
-  in Node.js).  Encryption of the communication over a WebSocket is supported as
-  a standard.
-- *HTTP protocol* -- The HTTP protocol is a state-less protocol implemented on
-  top of the TCP protocol.  The communication between the client and server
-  consists of a requests sent by the client and responses to these requests sent
-  back by the sever. The client can send as many requests as needed and it may
-  ignore the responses from the server, but the server must respond only to the
-  requests of the client and it cannot initiate communication on its own.
-  End-to-end encryption can be achieved easily using SSL (HTTPS).
-
-We chose the HTTP(S) protocol because of the simple implementation in all sorts
-of operating systems and runtime environments on both the client and the server
-side.
-
-The API of the server should expose basic CRUD (Create, Read, Update, Delete)
-operations. There are some options on what kind of messages to send over the
-HTTP:
-
-- SOAP -- a protocol for exchanging XML messages. It is very robust and complex.
-- REST -- is a stateless architecture style, not a protocol or a technology. It
-  relies on HTTP (but not necessarily) and its method verbs (e.g., GET, POST,
-  PUT, DELETE). It can fully implement the CRUD operations.
-
-Even though there are some other technologies we chose the REST style over the
-HTTP protocolo. It is widely used, there are many tools available for
-development and testing, and it is understood by programmers so it should be
-easy for a new developer with some experience in client-side applications to get
-to know with the ReCodEx API and develop a client application.
-
 ### API server
 
 The API server must handle HTTP requests and manage the state of the application