add download progress polling thread
This commit is contained in:
parent
9ea389ee2f
commit
7024a973b2
3 changed files with 80 additions and 13 deletions
|
@ -5,10 +5,24 @@ for it, in the terminal.
|
|||
Something better is needed for the [[webapp]]. There needs to be a
|
||||
way for the web app to know what the current progress is of all transfers.
|
||||
|
||||
To get this info for downloads, git-annex can watch the file as it arrives
|
||||
and use its size.
|
||||
|
||||
TODO: What about uploads? Will i have to parse rsync's progresss output?
|
||||
Feed it via a named pipe? Ugh. Check into librsync.
|
||||
|
||||
This is one of those potentially hidden but time consuming problems.
|
||||
|
||||
## downloads
|
||||
|
||||
* Watch temp file as it's coming in and use its size.
|
||||
This is the only option for some special remotes (ie, non-rsync).
|
||||
Can either poll every .5 seconds or so to check file size, or
|
||||
could use inotify. Implemented.
|
||||
* Feed rsync output into a parser and parse out a progress value. Ugly,
|
||||
failure prone, but potentially the least CPU-expensive option.
|
||||
* Use librsync. Note: It's not wire-compatiable with the actual rsync
|
||||
command.
|
||||
* Set up a FIFO, have rsync read from or write to that, and the FIFO
|
||||
feeder/reader then can update the transfer info. Generic enough to
|
||||
work for most (all?) special remotes, but also the most expensive option,
|
||||
involving another copy through memory of the whole file contents.
|
||||
|
||||
## uploads
|
||||
|
||||
Cannot use temp file, as we're not receiving it. Rsync progress parser,
|
||||
librsync, and FIFO all work.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue