comm analysis

Rewritten-docs.md

@@ -933,9 +933,26 @@ notable chance we would have to do the same with RabbitMQ). It also gives us
 complete control over the transmitted messages and communication patterns.
 However, all of the three options would have been possible to use.
 
+### File transfers
+
+There has to be a way to access files stored on the fileserver from both workers
+and clients. We will present some of the possible options:
+
+@todo elaborate this stuff
+
+- HTTP(S)
+- FTP
+- SFTP
+- A network-shared file system (such as NFS)
+- A custom protocol over ZeroMQ
+
+We chose HTTPS because it is widely used and clients exist in all relevant
+environments. In addition, it is highly probable we will have to run an HTTP
+server, because it is intended for ReCodEx to have a web frontend.
+
 ### Frontend - backend communication
 
-Our choices when considering how clients will communicate with the backend has
+Our choices when considering how clients will communicate with the backend have
 to stem from the fact that ReCodEx should primarily be a web application. This
 rules out ZeroMQ -- while it is very useful for asynchronous communication
 between backend components, it is practically impossible to use it from a web
@@ -978,9 +995,10 @@ 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.
 
-To sum up, chosen ways of communication inside the ReCodEx system are captured
-in the following image. Red connections are through ZeroMQ sockets, blue are
-through WebSockets and green are through HTTP(S).
+A high level view of chosen communication protocols in ReCodEx can be seen in
+following image. Red arrows mark connections through ZeroMQ sockets, blue mark
+WebSockets communication and green arrows connect nodes that communicate through
+HTTP(S).
 
 ![Communication schema](https://github.com/ReCodEx/wiki/raw/master/images/Backend_Connections.png)