add upload-status page: progress and to-whom info #92

New Issue

warner · 2007-07-25T03:33:15Z

warner commented

2007-07-25 03:33:15 +00:00

It would be nice if the upload POST form could bounce you to a page that would show useful information about the upload:

upload progress
- this couldn't cover the HTTP POST, but it could show encode/push progress
which peers the shares were given to, and how many went to whom

As Zooko and Sam pointed out, the most important thing this page could tell you would be that you've just uploaded the file to yourself, and therefore don't have the kind of reliability that you want.

It would be nice if the upload POST form could bounce you to a page that would show useful information about the upload: * upload progress * this couldn't cover the HTTP POST, but it could show encode/push progress * which peers the shares were given to, and how many went to whom As Zooko and Sam pointed out, the most important thing this page could tell you would be that you've just uploaded the file to yourself, and therefore don't have the kind of reliability that you want.

warner added the

labels 2007-07-25 03:33:15 +00:00

warner added this to the undecided milestone 2007-07-25 03:33:15 +00:00

warner self-assigned this 2007-07-25 03:33:15 +00:00

warner added

code-frontend-web

and removed

code

labels 2007-08-14 19:00:29 +00:00

zooko commented

2007-09-25 04:31:01 +00:00

merging in ticket #66.

This can also dovetail with the big "introduction/resource management/friendnet/etc." task for Milestone 0.7.0.

merging in ticket #66. This can also dovetail with the big "introduction/resource management/friendnet/etc." task for Milestone 0.7.0.

zooko added

0.6.0

and removed

0.4.0

labels 2007-09-25 04:31:01 +00:00

zooko modified the milestone from undecided to 0.7.0

2007-09-25 04:31:01 +00:00

zooko commented

2007-11-01 19:43:53 +00:00

We're focussing on an imminent v0.7.0 (see the roadmap) which hopefully has [#197 #197 -- Small Distributed Mutable Files] and also a fix for [#199 #199 -- bad SHA-256]. So I'm bumping less urgent tickets to v0.7.1.

We're focussing on an imminent v0.7.0 (see [the roadmap](http://allmydata.org/trac/tahoe/roadmap)) which hopefully has [#197 #197 -- Small Distributed Mutable Files] and also a fix for [#199 #199 -- bad SHA-256]. So I'm bumping less urgent tickets to v0.7.1.

zooko added

0.6.1

and removed

0.6.0

labels 2007-11-01 19:43:53 +00:00

zooko commented

2007-11-13 18:28:05 +00:00

We need to choose a manageable subset of desired improvements for [ http://allmydata.org/trac/tahoe/milestone/0.7.1 v0.7.1], scheduled for two week hence, so I'm bumping this one into v0.7.2, scheduled for mid-December.

We need to choose a manageable subset of desired improvements for [ <http://allmydata.org/trac/tahoe/milestone/0.7.1> v0.7.1], scheduled for two week hence, so I'm bumping this one into [v0.7.2](http://allmydata.org/trac/tahoe/milestone/0.7.2), scheduled for mid-December.

zooko added

0.7.0

and removed

0.6.1

labels 2007-11-13 18:28:05 +00:00

zooko added this to the undecided milestone 2008-01-23 04:19:51 +00:00

lebek commented

2012-02-02 22:55:31 +00:00

This ticket was discussed on IRC on 2/2/2012, the main points:

21:16 < lebek> [...] what if I start with the 'status/up-*' page, wouldn't need to affect upload flow.

21:22 < warner> lebek: yeah, starting with status/up-* would be a great idea, just enhancing it to have more/more-realtime information

[...]

21:26 < zooko> So the implementation of #92 in JS loads some json from the WAPI that contains the data.

21:26 < zooko> In that case #92 includes extensions to both the WUI and the WAPI.

21:27 < warner> so, I think the WAPI should have a method that starts an upload, and then another cluster of methods that let you find out about the upload (both the HTTP phase, the tahoe phase, and the post-upload results)

21:28 < warner> and the no-JS WUI can use some variant or alternative method that just redirects you to some static results page (or the directory page) when it finishes

21:28 < warner> and the yes-JS WUI can start the upload and then fetch progress updates to keep you pacified until it's done

[...]

22:01 < zooko> lebek: +1 on doc'ing the new WAPI interface, +1 on exposing HTTP phase separate from LAFS phase, and post-upload stats, and realtime display.

--- snip ---

Filling this ticket should probably require a fix for #1032.

Also related to the HTTP upload phase:

#951 (uploads aren't cancelled by closing the web page)

#1173 (cancelled downloads are marked incorrectly on the Recent Uploads/Downloads page)

Everyone agrees that changes should preserve current functionality for non-JS users.

This ticket was discussed on IRC on 2/2/2012, the main points: 21:16 < lebek> [...] what if I start with the 'status/up-*' page, wouldn't need to affect upload flow. 21:22 < warner> lebek: yeah, starting with status/up-* would be a great idea, just enhancing it to have more/more-realtime information [...] 21:26 < zooko> So the implementation of #92 in JS loads some json from the WAPI that contains the data. 21:26 < zooko> In that case #92 includes extensions to both the WUI and the WAPI. 21:27 < warner> so, I think the WAPI should have a method that starts an upload, and then another cluster of methods that let you find out about the upload (both the HTTP phase, the tahoe phase, and the post-upload results) 21:28 < warner> and the no-JS WUI can use some variant or alternative method that just redirects you to some static results page (or the directory page) when it finishes 21:28 < warner> and the yes-JS WUI can start the upload and then fetch progress updates to keep you pacified until it's done [...] 22:01 < zooko> lebek: +1 on doc'ing the new WAPI interface, +1 on exposing HTTP phase separate from LAFS phase, and post-upload stats, and realtime display. --- snip --- Filling this ticket should probably require a fix for #1032. Also related to the HTTP upload phase: #951 (uploads aren't cancelled by closing the web page) #1173 (cancelled downloads are marked incorrectly on the Recent Uploads/Downloads page) Everyone agrees that changes should preserve current functionality for non-JS users.

Sign in to join this conversation.