[or-cvs] [tor/master] Remove TODO items that are either done or moved to the tracker

[nickm at torproject.org]

Author: Nick Mathewson <nickm at torproject.org>
Date: Tue, 6 Jul 2010 18:10:53 -0400
Subject: Remove TODO items that are either done or moved to the tracker
Commit: f72c6f91deed6b076fd730d049c3bddbbb3eb329

---
 doc/TODO.022    |   25 ++++---------------------
 doc/TODO.future |    7 -------
 2 files changed, 4 insertions(+), 28 deletions(-)

diff --git a/doc/TODO.022 b/doc/TODO.022
index f4fe2eb..d83ed6e 100644
--- a/doc/TODO.022
+++ b/doc/TODO.022
@@ -8,29 +8,16 @@ NOTE 2: It's easy to list stuff like this with no time estimates and
         0.2.2, figure out how long the stuff we want will take, and
         triage accordingly, or vice versa.
 
-- Design only
-  - Begin design work for UDP transition; identify areas where we need to
-    make changes or instrument stuff early.
-    [multiple weeks, ongoing.  Need to do a draft early.]
-
 - Performance, mostly protocol-neutral.
-  - Work with Libevent 2.0's bufferevent interface
-    - Identify any performance stuff we need to push back into
-      libevent to make it as fast as we want.
-    - Get a decent rate-limiting feature into Libevent
-    - Get openssl support into Libevent.
 
-  - Revise how we do bandwidth limiting and round-robining between
+  o Revise how we do bandwidth limiting and round-robining between
     circuits on a connection.
 
-  - Revise how we do bandwidth limiting and round-robining between
+  . Revise how we do bandwidth limiting and round-robining between
     connections.
 
   - Better flow-control to avoid filling buffers on routers.
 
-  - Split AES across cores if possible.
-  - Split SSL across cores (reach; may require Libevent 2.1).
-
   - Figure out good ways to instrument Tor internals so we can tell
     how well our bandwidth and flow-control stuff is actually working.
     - What ports eat the bandwidth?
@@ -58,10 +45,6 @@ NOTE 2: It's easy to list stuff like this with no time estimates and
     - 158: microdescriptors
       o Revise proposal
       - Implement
-    o 160: list bandwidth in consensus
-      o Finish proposal
-      o and actually set it reasonably
-      o and actually use it.
 
   - Proposals to improve and implement if not broken
     D IPv6 support.  (Parts of 117, but figure out how to handle DNS
@@ -104,6 +87,6 @@ M?    - Write proposal
   - Switch to MSI on win32
   - Use Thandy, perhaps?
 
-- Deprecations
-  - Make .exit safe, or make it off-by-default.
+o Deprecations
+  o Make .exit safe, or make it off-by-default.
 
diff --git a/doc/TODO.future b/doc/TODO.future
index 4220799..85e07aa 100644
--- a/doc/TODO.future
+++ b/doc/TODO.future
@@ -22,7 +22,6 @@ K       - Karsten claims
 =======================================================================
 
 Later, unless people want to implement them now:
-  - tor as a socks proxy should accept (and ignore) password auth
   - Actually use SSL_shutdown to close our TLS connections.
   - Include "v" line in networkstatus getinfo values.
     [Nick: bridge authorities output a networkstatus that is missing
@@ -30,10 +29,6 @@ Later, unless people want to implement them now:
      bridgedb gives out bridges with certain characteristics. -RD]
     [Okay. Is this a separate item, or is it the same issue as the lack of
      a "v" line in response to the controller GETINFO command? -NM]
-  - Let tor dir mirrors proxy connections to the tor download site, so
-    if you know a bridge you can fetch the tor software.
-  - when somebody uses the controlport as an http proxy, give them
-    a "tor isn't an http proxy" error too like we do for the socks port.
   - MAYBE kill stalled circuits rather than stalled connections.  This is
     possible thanks to cell queues, but we need to consider the anonymity
     implications.
@@ -45,8 +40,6 @@ Later, unless people want to implement them now:
     online config documentation from a single source.
   - It would be potentially helpful to respond to https requests on
     the OR port by acting like an HTTPS server.
-  - Make the timestamp granularity on logs configurable, with default
-    of "1 second".  This might make some kinds of after-the-fact attack harder.
 
   - We should get smarter about handling address resolve failures, or
     addresses that resolve to local IPs.  It would be neat to retry
-- 
1.7.1