Hi, Folks. 

If it's not already planned, I'd like to request, when time allows, 
that an additional piece of information be added to the search result 
display page. We need to see the IP address of each source in the 
page. 

The reason this is needed is that when a download is resumed from a 
previous session, and the search is open so that current sources can 
be found, there is no way to tell if an entry in the search results
matches a source that is already downloading or in the download queue.
Unless the IP of the source is displayed, there is no way to match 
them up to existing download/queue selections.

In the case of a file that already completed downloading, the 
checkbox 'hide downloaded files' will allow the user to ignore files 
that have completed. But partially downloaded files from a previous 
session, which have restarted, can't currently be identified in the 
search panel as matching a particular source. The addition of the IP 
address as part of the source info would allow the user to manually 
match up the existing download slot and the source in the search 
results. 

Or an even better approach might be to just check the search results
against the current download/queue entries, and to not display them 
in the search results panel if they match an entry in either the 
queue or the active connections. Perhaps a flag could be added to the
file info, indicating if it should be displayed or not, so that the
screen updates could be done quickly without having to check each 
line against the download/queue entries. 

However it's implemented, I would not discard the search entry from 
the result set if it's active. Just mark it in some way as 'not to 
be displayed', so that if the connection to that particular source 
fails or aborts, it can be re-added later by re-selecting it. 

Or, alternately, search results that match an active download/queue
entry could be displayed in the results pane in some way that 
indicates that they have already been selected, so that the user 
won't try to select them a second time. I think that the user should 
actually be prevented from adding them to the download queue a second 
time.

Whatever approach is used should prevent the user from selecting the 
same file/source combination multiple times. It will also prevent the 
user from annoying the source owner, who might not like to receive 
additional requests from someone who is already enqueued, or already 
downloading. 

If this is already being done in some way that is not obvious, then 
the display needs to show it more clearly to the user. In other 
words, the user needs some way to know that a search entry has 
already been selected for download, so that they won't do it again. 
And the program needs to prevent duplicate entries in the queue. 

The reason I ask for this is I found that I did select a unique 
file/source combination multiple times, and was surprised to later 
find duplicate IP addresses in the download displays for the same 
file. 

It appears that most sources do prevent duplicate active downloads
to a particular user. But some of them don't prevent the user from 
queuing up a second download request of the same file. While it may 
do no harm to select a duplicate download from a source, it's not 
a useful feature either, and may annoy the source owner. And if it
actually downloaded twice, it would be wasting bandwidth, using up
double what was really needed. 

I also notice that the download page is just about the only page that 
does not support sorting by clicking on the column headings. Is this 
intentional, to always show the entries in 'time' order (i.e., oldest 
events are at the top, as is done with the connection information)? Or
is the code just not completed yet to allow this? I think it would be
useful to be able to sort downloads or queue entries by IP, so that 
it's easy to identify what requests are being served by a particular
server. It may be useful to know how many reqests are made to an IP
address, and it's not as easy to do unless the IP's are sorted.  

It would also be useful to break the status information up into 
more columns, so that the percent complete, current thruput, and
time remaining are in their columns. The 'status' column could then
be used only for 'active', 'queued', 'push sent', or the queue 
status. With multiple active downloads, I think this would make the 
display much more readable for the user. The current status format 
varies from item to item, depending on what client program is  
connected, I think, and it can be hard to get a feeling of the 
overall status at a glance. Breaking the info into more columns
will make it easier for the user to grasp the overall status in a 
glance. I have found this to be true in similar programs. 

Thanks,
--Carl




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gtk-gnutella-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

Reply via email to