RFC:
Start with the rationale: I have a couple of _large_ multimedia groups
that I read. alt.binaries.multimedia has close to 400K messages in it,
and a couple of mp3 groups almost as many.
I have a lot of RAM (768M) but even so, the system isn't very happy at
all when I try to download headers for three large groups at the same
time. Because the large groups take longer, they naturally tend to be
updated at the same time.
The natural way to limit this is to restrict to one or two connections
when downloading headers, and ramp up to four for reading. But this
involves remembering to open the dialog... and I'm lazy.
The suggestion: do this automatically. Have two classes of connect-
ions. one for headers, and one for articles, the maximum number of
connections for each to be set independantly. The actual total at any
time will of course not be more than 4.
The idea is that the downloader eats of the top of queue, grabbing the
first task that has a connection class which is not maxed out.
This will also allow the user to read loaded groups while others'
headers are still being updated. In the current scheme, since each
group takes a long time to load, even though interactive tasks get put
on the head of the queue, it can take a long time for them to get serviced.
In the proposed scheme, since we assume we have assigned a maximum of
(say) 3 connections to headers, there will be one left over for
reading articles.
I suspect that the old "reserve a connection for interactive tasks"
could be subsumed by this scheme, but I'm not entirely happy with what
I could come up with on the back of a napkin, so I'm omitting that bit
for now.
Right now, I was hoping that people would comment on this, and I'll
make a bugzilla entry if there is any interest.
johan
_______________________________________________
Pan-users mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/pan-users