Added to conclusion, process and recommendations.

Author: samuelaustin

.gitignore

@@ -4,3 +4,5 @@
 *.out
 *.swp
 *.synctex.gz
+*.toc
+main-blx.bib

Report/conclusion.tex

@@ -1,4 +1,6 @@
 \chapter{Conclusion}
-Based on the final product of the project it is safe to say that peer-to-peer applications involving streaming, downloading and uploading of files is possible on smart TV's. Due to hardware limitations the application was never able to reach its full potential but the results are very promising for future televisions with better hardware. Dispite the hardware issues, the technology does work which makes our application is the first fourth generation peer-to-peer file sharing application in the world.
+Unlike most bachelor projects, ours started in the third quarter of the year. During this time we worked part-time next to our regular courses to set up a development environment, which was quite a challenging task. This allowed us to begin development as soon as the fourth quarter started. The constant struggle against the constrainst of the TV was one of the things that made the project challenging and enjoyable. Developing on a device that nobody has really developed for before and having to solve new and unexpected problems along the way made this a very educational project.
 
-Another important aspect as to whether more advanced applications will be developed for televisions is the amount of freedom manufacturers are willing to give to developers. As it stands, television manufacturers seem very weary of giving any access to their TV's, which is very understandable from a security point of view. However, if the full potential of the smart TV is to be reached, developers must be given full access to develop advanced programs or else the smart TV will remain a gimmick with limited functionality.
+Based on the final product it is safe to say that peer-to-peer applications involving streaming, downloading and uploading of files is possible on smart TV\textquotesingle s. Due to hardware limitations the application was never able to reach its full potential but the results are very promising for future televisions with better hardware. Despite the hardware issues, the technology does work which makes our application the first fourth generation peer-to-peer file sharing application on a smart tv in the world.
+
+Another important aspect, next to better hardware, as to whether more advanced applications will be developed for televisions is the amount of freedom manufacturers are willing to give to developers. As it stands, television manufacturers seem very weary of giving any access to their TV\textquotesingle s, which is very understandable from a security point of view. However, if the full potential of the smart TV is to be reached, developers must be given full access to develop advanced programs or else the smart TV will remain a gimmick with limited functionality.

Report/further_recommendations.tex

@@ -3,3 +3,6 @@ \chapter{Recommendations}
 
 A major limitation during this project was the hardware in the television. The application we built depends on reasonably heavy python programs and requires quite a lot of memory when streaming. Although the CPU seemed to be able to keep up, the lack of memory was very noticable when streaming. Thankfully, as technology improves and becomes cheaper, televisions will get better hardware and it will not be long untill they will be able to easily run application like this one. For future versions of peer-to-peer applications on televisions, better hardware is a must.
 
+Once televisions are powerfull enough to handle high quality video streaming, a better version of the application can be created. Although we were very happy with the back-end of our application, the GUI part was not as refined because our focus was on the back-end. In order to make the application more user friendly the GUI needs to be improved. Thanks to the way our application is made, any GUI that can send HTTP requests and parse XML is able to interface with our application which makes changing to a completely different GUI very easy.
+
+At the moment Dispersy and DHT are built into Tribler. When we needed both these services we were forced to run Tribler with a bunch of modules switched off, just leaving Dispersy, DHT and some other necessary elements. It would be better if Dispersy and DHT could be run as independent modules.

Report/main-blx.bib

@@ -1,11 +1,11 @@
 @Comment{$ biblatex control file $}
-@Comment{$ biblatex version 1.4 $}
+@Comment{$ biblatex version 1.7 $}
 Do not modify this file!
 
 This is an auxiliary file used by the 'biblatex' package.
 This file may safely be deleted. It will be recreated as
 required.
 
 @Control{biblatex-control,
-  options = {1.4:0:0:1:0:0:1:1:0:0:0:0:1:1:3:1:79:+},
+  options = {1.7:0:0:1:0:0:1:1:0:0:0:0:1:1:3:1:79:+},
 }

Report/main.toc

@@ -74,6 +74,14 @@
 \defcounter {refsection}{0}\relax 
 \contentsline {section}{\numberline {5.3}Python}{31}{section.5.3}
 \defcounter {refsection}{0}\relax 
+\contentsline {section}{\numberline {5.4}Changes during development}{31}{section.5.4}
+\defcounter {refsection}{0}\relax 
+\contentsline {subsection}{\numberline {5.4.1}Upload visibility}{31}{subsection.5.4.1}
+\defcounter {refsection}{0}\relax 
+\contentsline {subsection}{\numberline {5.4.2}Number of downloads}{31}{subsection.5.4.2}
+\defcounter {refsection}{0}\relax 
+\contentsline {subsection}{\numberline {5.4.3}Excluded features}{31}{subsection.5.4.3}
+\defcounter {refsection}{0}\relax 
 \contentsline {chapter}{\numberline {6}Process}{32}{chapter.6}
 \defcounter {refsection}{0}\relax 
 \contentsline {section}{\numberline {6.1}Planning}{32}{section.6.1}
@@ -86,11 +94,11 @@
 \defcounter {refsection}{0}\relax 
 \contentsline {subsection}{\numberline {6.3.2}Installing missing dependencies}{34}{subsection.6.3.2}
 \defcounter {refsection}{0}\relax 
-\contentsline {subsection}{\numberline {6.3.3}TCP Reset packages}{34}{subsection.6.3.3}
+\contentsline {subsection}{\numberline {6.3.3}TCP Reset packages}{35}{subsection.6.3.3}
 \defcounter {refsection}{0}\relax 
-\contentsline {subsection}{\numberline {6.3.4}Classical fork() and thread problem}{34}{subsection.6.3.4}
+\contentsline {subsection}{\numberline {6.3.4}Classical fork() and thread problem}{35}{subsection.6.3.4}
 \defcounter {refsection}{0}\relax 
-\contentsline {subsection}{\numberline {6.3.5}Communication between javascript and C++}{34}{subsection.6.3.5}
+\contentsline {subsection}{\numberline {6.3.5}Communication between javascript and C++}{35}{subsection.6.3.5}
 \defcounter {refsection}{0}\relax 
 \contentsline {subsection}{\numberline {6.3.6}Starting the HTTP server}{35}{subsection.6.3.6}
 \defcounter {refsection}{0}\relax 

Report/process.tex

@@ -16,7 +16,7 @@ \section{Testing}
 
 We only wrote tests for C++ as this was the core of our application. We made use of the google test library which allowed for easy implementation of unit tests. The tests were developed in parallel with the development of the application which allowed for constant checking for bugs with every change. This way most bugs were immediatly discovered and removed as soon as they appeared. Writing the tests also helped making the system robust and able to handle unexpected input and calls without crashing.
 \\\\
-Almost every method has its own tests, usually a trivial test and additionally a couple of tests with unexpected input. Certain classes, especially DownloadManager, required test cases to call multiple different methods in order to test certain situations. Although this resulted in some relatively long test cases it did guarentee a solid application capable of handling a large range of situations.
+Every class has its own test class and almost every method has its own tests, usually a trivial test and additionally a couple of tests with unexpected input or unexpected situations. Certain classes, especially DownloadManager, required test cases to call multiple different methods in order to test certain situations. Although this resulted in some relatively long test cases it did guarentee a solid application capable of handling a large range of exceptional situations.
 \\\\
 We chose not to fully test SearchEngine, the reason being that SearchEngine relies on dispersy and DHT. Both of these services are unreliable when it comes to returning search results, you do not always get the same results and sometimes you get no results. The testing environment requires a fixed return value every time. In order to achieve this we created a mock of the SearchEngine class which has the same functionality as the real SearchEngine except when it comes to searching. The mock always returns the exact same results which are hard coded in the mock. This allowed us to test HttpServer without having to worry about dispersy and DHT returning different values every time.