starting with a clean slate

[functorrent.git] / doc / design.md

diff --git a/doc/design.md b/doc/design.md
deleted file mode 100644 (file)
index e5dbd9d..0000000
--- a/doc/design.md
+++ /dev/null
@@ -1,53 +0,0 @@
-2016-03-10:
-
-A rough sketch of the design of the program.
-
-In the Unix tradition, FuncTorrent takes either a .torrent file as input or one
-can `cat' the .torrent file and pipe the output into the program:
-
-$ cat foo.torrent | ./functorrent
-
-As of 10/Mar/2016, FuncTorrent supports only HTTP tracker.
-
-Each module starts up as a thread, so we have FileSystem thread, we have a Tracker
-Client thread. We have a main client thread, that receives pieces. We also have a 
-Server thread that serves pieces.
-
-The messages themselves are not exposed outside the module. Instead, a function that
-create a message passing channel is exposed and also helper functions that talk via
-the channel to the module are also exposed. So, it is the duty of the Module to expose
-relevant functions that sends/receives messages.
-
-Tracker
--------
-
-Tracker module has two submodules: one for Http and another for Udp. UDP one is not
-ready yet. So, let us talk about http. The tracker module would take care of dispatching
-to the apropriate module (udp or http) depending on the tracker server url that we
-decode from the .torrent file. The Tracker currently takes two messages: one to get the
-tracker status (tracker url could be defunct and could time out or the tracker server
-may return a genuine error response, which is captured in a bytestring). The module 
-has an 'newTracker' function, that just creates a new channel. It also has a 'runTracker'
-function that takes the above created channel and a bunch of parameters including the
-FileSystem channel (since FileSystem module is the 'owner' of the bytes read/write
-statistics). It then spawns a thread that talks to the tracker server and the rest of
-the function is a loop which is looking for and handling messages on the msg channel.
-
-Tracker messages are defined in Tracker/Types.hs
-
-data TrackerMsg = GetStatusMsg TrackerEventState
-                | GetConnectedPeersMsg (MVar [Peer])
-
-i.e. There are two messages. GetStatusMsg is to get the current state of the TrackerClient (us)
-to Tracker Server communication. TrackerEventState is also defined in Tracker/Types.hs as
-
-data TrackerEventState = None
-                       | Started
-                       | Completed
-                       | Error ByteString
-                       deriving (Show, Eq)
-
-In particular, the Error EventState signifies any possible error signalled by the
-server, based on which, the user of the Tracker module can take some action.
-
-So, once started,