tahoe-lafs/trac

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

New issue

Open

opened 2007-07-25 03:33:15 +00:00 by warner · 4 comments

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

c/code-frontend-web

and removed

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

and removed

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

and removed

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

and removed

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

Owner

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.

No labels

c/code-dirnodes

c/code-encoding

c/code-frontend

c/code-frontend-cli

c/code-frontend-ftp-sftp

c/code-frontend-magic-folder

c/code-frontend-web

c/code-nodeadmin

c/code-peerselection

c/dev-infrastructure

kw:AttributeError

kw:DataUnavailable

kw:DeadReferenceError

kw:GetLastError

kw:IFinishableConsumer

kw:LeastAuthority

kw:RIStorageServer

kw:UncoordinatedWriteError

kw:access-control

kw:accessibility

kw:accounting-crawler

kw:anti-censorship

kw:api_auth_token

kw:authentication

kw:availability

kw:backward-compatibility

kw:blocks-cloud-deployment

kw:blocks-cloud-merge

kw:blocks-magic-folder-merge

kw:blocks-merge

kw:blocks-release

kw:brians-opinion-needed

kw:build-helpers

kw:cloud-backend

kw:coding-standards

kw:coding-tools

kw:coding_tools

kw:compatibility

kw:confidentiality

kw:configuration

kw:configuration.txt

kw:connectivity

kw:control.furl

kw:coordination

kw:coveralls.io

kw:create-container

kw:cryptography

kw:cryptography-lib

kw:denial-of-service

kw:desert-island

kw:desert-island-build

kw:design-review-needed

kw:dev-infrastructure

kw:directory-page

kw:disk-backend

kw:earth-dragon

kw:erasure-coding

kw:excess-authority

kw:extensibility

kw:file-descriptor

kw:floatingpoint

kw:forward-compatibility

kw:forward-secrecy

kw:garbage-collection

kw:google-cloud-storage

kw:google-drive-backend

kw:grid-manager

kw:illustration

kw:inlineCallbacks

kw:integration-test

kw:interoperability

kw:interstellar-exploration

kw:introduction

kw:key-value-store

kw:magic-folder

kw:manual-test-needed

kw:more-info-needed

kw:mountain-lion

kw:multiuser-gateway

kw:needs-review

kw:notification

kw:notifyOnDisconnect

kw:openitp-packaging

kw:operation-helpers

kw:optimization

kw:organization

kw:otf-magic-folder-objective1

kw:otf-magic-folder-objective2

kw:otf-magic-folder-objective3

kw:otf-magic-folder-objective4

kw:otf-magic-folder-objective5

kw:otf-magic-folder-objective6

kw:peer-selection

kw:pkg_resources

kw:preservation

kw:pycrypto-lib

kw:pyfilesystem

kw:random-access

kw:raspberry-pi

kw:release-blocker

kw:removable-disk

kw:reserved_space

kw:response-needed

kw:response-time

kw:review-needed

kw:self-contained

kw:servers-of-happiness

kw:setup_requires

kw:setuptools_darcs

kw:simultaneous

kw:space-efficiency

kw:static-analysis

kw:stats_gatherer

kw:tahoe-add-alias

kw:tahoe-archive

kw:tahoe-backup

kw:tahoe-create-alias

kw:tahoe-create-introducer

kw:tahoe-deep-check

kw:tahoe-deepcheck

kw:tahoe-lafs-trac-stream

kw:tahoe-list-aliases

kw:tahoe-magic-folder

kw:tahoe-manifest

kw:tahoe-restart

kw:tahoe-unlink

kw:tahoe-webopen

kw:test-and-set

kw:test-from-egg

kw:ticket999-s3-backend

kw:to-be-closed-on-2011-08-01

kw:tor-protocol

kw:transparency

kw:tub.location

kw:twisted-trial

kw:uncoordinated-writes

kw:unfinished-business

kw:unhandled-error

kw:upload-helper

kw:visualization

kw:volunteergrid2

kw:warners-opinion-needed

kw:welcome-page

kw:windows-related

kw:world-domination

kw:write-enabler

kw:zookos-opinion-needed

kw:zope.interface

p/supercritical

r/cannot reproduce

r/somebody else's problem

r/was already fixed

v/1.9.0-s3branch

No milestone

No project

No assignees

3 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac#92

No description provided.