some questions about uploader

[Eli Cochran]

Justin,
I'm going to take this to the list since your questions are right on,  
and I'd like to give others a chance to chime in with other opinions.

Comments inline...

On May 12, 2008, at 11:10 AM, Justin Obara wrote:

> Hello Eli,
>
> As I had mentioned in the standup today, I'm working on a test  
> protocol for the Uploader.
>
> I've played around with it for a bit and just had a few questions  
> about the correct functionality of Uploader. (http://build.fluidproject.org/sakai-imagegallery-tool/sample-code/uploader/inline/index.html 
> )
>
> Michelle had directed me to the wiki entry (http://wiki.fluidproject.org/display/fluid/Multi-File+Uploader+Overview 
> ), but I still had a few left over questions.
>
> 1) Should the "Files to Upload" size be the total of all files in  
> the queue, including files which were already uploaded, or just the  
> ones to be uploaded?
>        - Currently it shows the total of all files if you do an  
> upload, and then browse and add some more to the queue. If you do an  
> upload of multiple files and pause the upload progress, the "Files  
> to Upload" size is equal to that of the remaining files. I am  
> assuming that the latter method is the intended way, but not sure.

Files to upload should represent the file count and total size of the  
files not yet uploaded, not the cumulative total. But if you had to  
ask the question then I think that UI isn't completely clear.

> 2) Here is a two part question.
>     a) If a large file is paused in the middle, is it supposed to  
> resume from where it was left off or is the partial upload deleted?

The partial upload is deleted. There is no way to resume a partial  
upload. There are a number of good back-end reasons for this.

>     b) If the partial download is not deleted, what happens to it if  
> the user clicks "Cancel" (or clicks the remove button) after  
> clicking pause? Will the file be left in the queue, will it be  
> deleted from the system, or will it just sit on the hdd for someone  
> else to delete?

Irrespective of the lack of partial upload, the Cancel button is an  
interesting question and partially up to the capabilities built into  
the back-end (which we are not specifying but I'm wondering if we  
should recommend behavior). My recommended behavior would be that when  
the back-end gets a "Cancel" that it should discard the entire upload  
session since that is consistent with what Cancel usually means.


> 3) Currently the user is able to add multiple instances of the same  
> file (with the same name) to the file queue and upload them. I am  
> assuming that this should not be allowed. Will there be some error  
> message given to the user? Similarly will the user be able to upload  
> a file with an identical name and type to one that already resides  
> in the upload folder or will they be warned? Unfortunately I cannot  
> test this out myself right now, as the upload process is only  
> simulated.

Great question and another one of those tricky spots.

Here is the scenario that the uploader is supposed to be able to  
support: user selects file A from folder Foo, and then selects file A  
from folder Bar. Foo/A and Bar/A are different files, but there is  
nothing in the Uploader that knows that A in our list is Foo/A or Bar/ 
A, so we really can't discern whether they are different files or the  
same files. [For security reasons, our good friends at Adobe have  
decided that we *can't* know, even if we ask nicely.]

We could have a quick and dirty rule in the Uploader that says we do  
not accept two files with the same names, or (better) two files with  
the same names of the same exact size. In the context of one person's  
computer, it is quite possible that there are two files with the same  
name and exact size that actually have different contents. But  
tripping over them in the course of one upload session are pretty slim.

Right now, we don't check for this case at all.

And again, the back-end should have a policy for this and handle it.  
The back-end could do a quick hash on the file data, and use the more  
robust criteria that two files with the same name and the same hash  
are not allowed. The Uploader then needs to be able to accept and  
display an error in that case.

Thank you for taking on this task.

- Eli

>
>
>
> Thanks
> Justin

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080512/807049ac/attachment.html>