progress.txt

Week 1: 
Research carried out into package mangers existing. A spreadsheet was built on google docs with a list of managers and their types.
A paper entitled apt-p2p was read, describing a debain package maneger layer above apt which attempted to pull packages from peers before resorting the the central servers. It used distributed hash tables to store peer information.

Week 2:
Further research into package manegers, further refining the types and which level they operated on (software or OS)
2 Papers were read this week, both from the same author attempting to build a fully fledged package peer to peer package manager, learning from previous attempts. Things to note, bittorrent is in effective to transfer packages as 85% of packages are under the minimum chunk size for bit torrent. Apt-p2p attempted to fix this by using distributed hash tables, which do infact do a better job, however they are heavy and for lighter devices can cause issues.
Also noteworthy was his attempt to build a global package manager for all devices big and small. He planned to implement peer "neibourhoods" which knew about packages they all had a common interest in. They could subscribe to packages they were interested in via a shared notice board. Publishers could update packages and have the notice boards inform peers there was a new version avalible to get which would then propagate through the network.

Week 3:
Much discussion took place regarding the future of the project, considering
the ammount of previous research put into the area. We had a brain storming
session and came out with an idea to change the project direction to look at
package recommendations. We spoke about a system that records what users
install and uses this data on a backend to make recommndations to users based
on what they already have installed/are currently installing.

Week 4:
The idea was futher discussed and systems currently being used were
investigated. One of note was NuGet Concierge which supports .net packages.
This manager implemented a graph based recommnedation engine which told users
what other packages were popularly installed with the ones they had. However
this uses a 1-1 relation between packages, and doesn't look through the 'web'
of packages.
Discussion was had regarding using RPM and DNF (Fedora's new package manager
replacing Yum) for the project.

Week 5: 
It was discovered that DNF allows plugins which we can use to implement our
system on the user's side. We discussed a system diagram with our plugin
grabbing a list of user's packages when installed and feeding that to a
backend server we run. Everytime the user does operations with DNF, our plugin
can also do work to find recommndations. 

Week 6:
This week we discussed moving forward in the project, how best to start implementation. We decided it would be best to start with the plugin and a mock API, allowing us to simulate the client-side interactions with the server.
I now have a diagram of the system and a mock API, plus looked into a DNF plugin, which seems fairly trivial.`

Week 7:
This week we discussed writing the plugin fully with a mock API for next week in an attempt to get a 'Wizard of Oz' style demo working.

Week 8: 
Spent this week getting initial support for the plugin working, so users can use the commands but they don't do anything

Week 9: 
This week was spent making the backend server to reply to the mock frontend

Week 10:
This week tidied up front end plugin, made the backend reply with some useful JSON

Week 11: