streaming uploads
authorJoey Hess <joeyh@joeyh.name>
Tue, 15 Oct 2024 20:02:19 +0000 (16:02 -0400)
committerJoey Hess <joeyh@joeyh.name>
Tue, 15 Oct 2024 20:02:19 +0000 (16:02 -0400)
doc/design/passthrough_proxy.mdwn
doc/todo/git-annex_proxies.mdwn

index 578b79a427352716a8efdc48f29925a30279a769..c6b5f57b27ddf14fcca8c28231d33512ec0824f7 100644 (file)
@@ -411,6 +411,15 @@ sending SUCCESS, leading to a perhaps long delay on the client before an
 upload finishes. Perhaps extend the P2P protocol with progress information
 for the uploads?
 
+To stream uploads via the proxy, storeKey would need its interface changed
+to not read the object file itself, but read from eg a lazy ByteString.
+Chunking and encryption would complicate that. Chunking seems fairly
+straightforward since it uses a lazy ByteString internally.
+storeExport would change similarly. The external special remote protocol
+would also need a change if it was to support that.
+
+----
+
 Both of those file-based approaches need the proxy to have enough free disk
 space to buffer the largest file, times the number of concurrent
 uploads+downloads. So the proxy will need to check annex.diskreserve
index 662b8c7a5d624a024bc5d02758628128830f12f3..50d1561073c88373a707c8bbddf6d5fb5167e285 100644 (file)
@@ -28,9 +28,12 @@ Planned schedule of work:
 
 ## work notes
 
-* Currently working on streaming download via proxy from special remote
+* Currently working on streaming special remotes via proxy 
   in the `streamproxy` branch.
 
+* Downloads from special remotes can stream (though using a temp file on
+  the proxy). Next: Streaming uploads via the proxy.
+
 ## completed items for September's work on proving behavior of preferred content
 
 * Static analysis to detect "not present", "not balanced", and similar