Ignore unknown cache files during directory scan.

[quix0rs-apt-p2p.git] / TODO

diff --git a/TODO b/TODO
index bb5ae3de303f5f2ffb0c3f4c280c029cbd7cfe76..d871ee1c716c37f63010e0eafd9ce68e9fd0633c 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,15 +1,8 @@
-Comply with the newly defined protocol on the web page.
+Consider what happens when we are the closest node.
 
-Various things need to done to comply with the newly defined protocol:
- - standardize the error messages (especially for a bad token)
-
-
-Reduce the memory footprint by clearing the AptPackages caches.
-
-The memory usage is a little bit high due to keeping the AptPackages
-caches always. Instead, they should timeout after a period of inactivity
-(say 15 minutes), and unload themselves from meory. It only takes a few
-seconds to reload, so this should not be an issue.
+In some of the actions it is unclear what happens when we are one of the
+closest nodes to the target key. Do we store values that we publish
+ourself?
 
 
 Packages.diff files need to be considered.
@@ -90,27 +83,3 @@ These should be combined (multiplied) to provide a sort order for peers
 available to download from, which can then be used to assign new 
 downloads to peers. Pieces should be downloaded from the best peers 
 first (i.e. piece 0 from the absolute best peer).
-
-
-When looking up values, DHT should return nodes and values.
-
-When a key has multiple values in the DHT, returning a stored value may not
-be sufficient, as then no more nodes can be contacted to get more stored
-values. Instead, return both the stored values and the list of closest
-nodes so that the peer doing the lookup can decide when to stop looking
-(when it has received enough values).
-
-Instead of returning both, a new method could be added, "lookup_value".
-This method will be like "get_value", except that every node will always
-return a list of nodes, as well as the number of values it has for that
-key. Once a querying node has found enough values (or all of them), then
-it would send the "get_value" method to the nodes that have the most
-values. The "get_value" query could also have a new parameter "number",
-which is the maximum number of values to return.
-
-
-Missing Kademlia implementation details are needed.
-
-The current implementation is missing some important features, mostly 
-focussed on storing values:
- - values need to be republished (every hour?)