Opened at 2008-02-12T03:10:30Z
Closed at 2008-05-09T21:35:12Z
#310 closed enhancement (fixed)
webish page to show currently active uploads/downloads
| Reported by: | warner | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 1.0.0 |
| Component: | code-frontend-web | Version: | 0.7.0 |
| Keywords: | Cc: | warner | |
| Launchpad Bug: |
Description
For testing (as well as for other uses), it would be convenient to have a webish page that lists all currently active uploads and downloads. For security purposes it is important that this page not provide private information about the files (i.e. their read/write caps), but it would be safe to disclose storage index, total file size, and progress information.
This is especially useful when dragging files into a FUSE-based virtual drive, to find out how much progress the Tahoe node has made towards uploading the file (since at least initially the FUSE plugin dropped a 0-byte file as a placeholder before doing the actual upload).
I'm thinking 'GET /status' (and maybe 'GET /status?t=json' for a machine-readable form).
Change History (2)
comment:1 Changed at 2008-02-12T04:31:46Z by warner
comment:2 Changed at 2008-05-09T21:35:12Z by zooko
- Cc warner added
- Milestone changed from undecided to 1.0.0
- Resolution set to fixed
- Status changed from new to closed
Well, I guess this one is done! Let's close it.
See also #92 (upload progress and to-whom), and #39 (log of recent uploads/downloads)
The to-whom/from-whom data would be a great thing to see on the status page.
I also agree that seeing recent uploads/downloads would be convenient, especially if there isn't a good way to view this data right after an upload (the 'upload results' page which I just added).
Maybe we could add a web page named /status/upload/$SI or /status/download/$SI that would provide details about the most recent upload/download of the given file. Then 'POST /uri' or 'POST /uri/PATH' could redirect the browser to one of these pages, possibly with some extra queryargs to enable links back to the directory being modified.
The code that I'm writing now puts the IDownloadStatus methods directly on the Downloader object, so to show status after the download has finished, we'd have to keep the Downloader around for a while (with a timer instead of / in addition to the current weakref scheme). I'd want to know how much memory this represents, however. Perhaps a separate DownloadStatus object (referenced+updated by the Downloader) would be better.