On Fri, 02 Sep 2005 12:16:54 +0100, Matthew Toseland wrote: > On Fri, Sep 02, 2005 at 12:09:34PM +0100, Ian Clarke wrote: >> On 2 Sep 2005, at 12:01, Matthew Toseland wrote: >> >Excellent idea. Implies we have a web interface to the queue, which >> >IMHO >> >is important anyway. Ian disagrees though. :| >> >> Actually I don't, and never have. I have no problem with exposing >> details of what is in the download queue in the web interface, I simply >> don't think we should try to handle downloads in their entirety through >> the web interface, rather I think this needs to be outsourced to >> third-party apps that can do the job in a proper, user friendly manner, >> rather than some kind of kludge as we have pre-0.7. > > Compromize: > - Have a convenient way to add a download to the queue from inside > fproxy, replacing the current splitfile form. > - Notify the user (low priority notification, shows up on the main web > interface page, clients can read them too) when there are completed > files in the completed-downloads directory. User can then delete them > etc, or third party clients can read them and then have the node zap > them. > - Web interface provides a simple list of queued files with progress > bars, transfer rate, size etc.
Just copy MLDonkey's web interface to files in transfer. No reason to reinvent the wheel when there's already a tested and proven to work solution available. It contains all the things you mentioned, plus two important additions - sorting (by any information column) and priority. And cancel and pause/unpause for each download, of course. MLDonkey can be downloaded from http://savannah.nongnu.org/projects/mldonkey/ if you want to have a look. It requires Objective-Caml to compile, which can be downloaded from http://caml.inria.fr/download.en.html You'd simply need to keep finished files in the interface, instead of removing them (as MLDonkey does).
