working in streamproxy branch

diff --git a/doc/todo/git-annex_proxies.mdwn b/doc/todo/git-annex_proxies.mdwn
index e88b7aad280180aaa38a351623219ce4bb6c4c41..662b8c7a5d624a024bc5d02758628128830f12f3 100644 (file)
--- a/doc/todo/git-annex_proxies.mdwn
+++ b/doc/todo/git-annex_proxies.mdwn
@@ -28,29 +28,8 @@ Planned schedule of work:
 
 ## work notes
 
-* Currently working on streaming download via proxy from special remote.
-
-* Tried implementing a background thread in the proxy that runs while
-  retrieving a file, to stream it out as it comes in. That failed because
-  reading from a file that the same process is writing to is prevented by
-  locking in haskell. (Could be gotten around by using FD rather than Handle,
-  but would need to read from the FD and use packCString to make a ByteString.)
-  
-  But also, remotes using fileRetriever retrieve to the temp object file,
-  before it is renamed to the requested file. In the case of a proxy,
-  that is a different file, and so it won't see the file until it's all
-  been transferred and renamed.
-
-* Could the P2P protocol be used as an alternate interface for a special
-  remote? Would avoid needing temp files when proxying for special remotes,
-  and would support resume from offset as well for special remotes for
-  which that makes sense.
-
-  But this would need encryption and chunking to be implemented on top of
-  the P2P protocol, and all special remotes rewritten, and a bridge for the
-  current external special remote interface or rewrite all external special
-  remotes. Probably not worth it to unify the two things like this, if the
-  only benefit is streaming through a proxy.
+* Currently working on streaming download via proxy from special remote
+  in the `streamproxy` branch.
 
 ## completed items for September's work on proving behavior of preferred content