streaming uploads
This commit is contained in:
parent
6eb32468bc
commit
c4dfeaef53
2 changed files with 13 additions and 1 deletions
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in a new issue