search

emorrp1 / mintupload

Uploads files on the Internet
http://emorrp1.github.com/mintupload
6 stars 21 forks source link

multiple file upload #4

Closed emorrp1 closed 15 years ago

emorrp1 commented 15 years ago

use case: Joe wants to upload more than one file to the service. He selects multiple files in the file browser, right-clicks and selects upload, but only one file is uploaded (if any, can someone with a right-click option test this). Instead, all the files should be uploaded, listed in the gui, and their urls outputted.

emorrp1 commented 15 years ago

note that this would be easier to implement in the CLI than the GTK however this would ruin the nice new progress bar, unless something else is done

kinkerl commented 15 years ago

i made a (crappy) mashup for the gui when uploading multiple files http://files.digitalkultur.net/stash/multiplefile.pdf the progressbar becomes obsolete after a finished upload. so it gets replaced by the url for the file.

i dont know anything about glade so i am not able to create this behavior.

emorrp1 commented 15 years ago

Ok, so I really like the progressbar --> url idea, as you're right the progressbar is useless once upload is complete. As this applies even to the single-file upload, can you create a new issue to track it seperately?

In terms of the actual implementation (http://github.com/kinkerl/mintupload/commit/2c04536f24eb640f09cb77b1efb6aaed9062a75f ), it's great that you've got something that presumably works, but I was hoping we could keep, and even expand on the multi-threadedness. By this I mean that rather than using a list of filenames inside mintUploader, it would be good if you could try to make it possible to just create a new instance of mintUploader for each upload. One advantage of using multiple threads would be the ability to upload them simultaneously, rather than sequentially.

Other related ideas: when a new file is selected for upload, add it to the current window. Change the gui for the progressbar section, it should be a list somehow, where new uploads could be appended, like in the services config window. Also, the filename section would need to be more integrated with the progressbars, as a single lone filename bit would be weird for multiple uploads.

kinkerl commented 15 years ago

issue is created for the progressbar -> url

the simultaneously uploading is no problem. but i think a new entry in the configuration is needed to define the number of simultaneous uploads. the default will be 2 uploads per server (this is save for most servers)

hm. its possible to add some sort of "drop handler" to handle drag n drop. i implemented this in java and its quite easy. this way, new files can be dropt in mintUpload and then get queued for upload.

emorrp1 commented 15 years ago

mmm, drag 'n' drop, I like it! At the moment there's several feature requests regarding multiple-file upload, and we've just been putting them in this thread. Perhaps consider (non-essential) opening new issues, but "labelling" them with multi-file or something, as I did for the config file.

Not sure I like the Idea of an artificial limit on the number of simultaneous uploads. Do you have have access to one of these servers? If so, what happens if you overload it? Do the extra uploads get queued or dropped? Is it the number of connections that's limited?

kinkerl commented 15 years ago

with the normal webservers i know, ssh and ftp is limited to 2 connections at the same time. other onnections get dropped and may even result in a temporary ban. and (if i remember correctly) depending on the connectiontype, more than 10 transfers result in to much overhead and longer responsetimes with lost bandwith as a result.

the bottleneck is initialisation of the connection (handshake). parallel handshakes will speed things up. the actual transfer is already quite fast and cant be faster with multiple connections. if the upload is limited to 100kb/sec by your internet connection, 2 uploads result in ((2 x 50kb/sec) - overhead).

i think 2 connections are the best (default) way to go and will result in the best performance.

emorrp1 commented 15 years ago

Oh I see what you mean, our upload speed to server is the limit rather than the server's incoming speed, hence multiple uploads just divide our bandwidth. Fair enough for the artificial limit of 2 by default, but the implementation shouldn't be designed to this limit, so it can be configurable.

emorrp1 commented 15 years ago

Fix Committed at kinkerl/multiupload, refresh method is still a bit buggy

emorrp1 commented 15 years ago

fixed the refresh method, it all works, just need to fix the gui to be nicer.