[Pan-users] Re: [Wishlist] Download algorithm improvement

[Duncan]

Eric Ortega posted <address@hidden>, excerpted below, 
on Fri, 12 Sep 2003 09:46:52 -0700:

> On Fri, Sep 12, 2003 at 04:54:54PM +0200, Sven Neuhaus wrote:
> 
>> My news server allows 3 parallel connections and I download 20 multipart 
>> files, I think it would be better if pan worked with all connections on one 
>> file at a time (downloading 3 different parts of the same multipart until 
>> there are less than 3 parts left, then start on the next file).
>> This would also help getting the oldest file quickest before it expires (if 
>> it is about to).
> 
> PAN has been doing this for a while now, I thought.

Yes.  It came with the switch to gnet for d/l handling.  I've been
enjoying the feature for some time.

However..  it does depend on how U set up the d/ls.  PAN puts all
connections to work on the same /task/, but not /necessarily/ the same
multi-part -- unless U create a task 4 each multi-part.  Otherwise, it
takes them in whatever order you marked them for d/l in, for that task.

The thing I find frustrating isn't this issue, directly, but is somewhat
related.  When U check the "show complete multi-part posts as a single
article" option, and then select that article to d/l as part of a bunch of
articles, it only d/ls the part shown -- the first part.  It doesn't d/l
the rest until you click on it to display what should have already been
d/led.  THEN it wants to go d/l them, when U THOUGHT U told it to d/l
everything b4, but it skipped the unshown parts of the multipart.  Of
course, U can set it to display all separate parts, select all, and hit
d/l, then switch it back to displaying completes as only a single article,
and get them all that way, but that's a big hassle that really shouldn't
be necessary.  One can also use save attachments rather than simply
d/ling, but that tends to clutter up the d/l dir, particularly if there's
a series of multiparts, and U find out with the first one you view that U
don't want to save the others.  If they were all d/led to (a sufficiently
large configured) cache, then one could just delete the undecoded messages
and only have the one file to delete, while using save-attachment means
deleting BOTH all the files, AND all the messages, PLUS the extra time and
CPU cycles to decode the stuff U otherwise would have deleted directly
from the cache, while still avoiding having to wait for it to d/l
interactively.

I suppose I should file a bug report..

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin