Blue (or was it yellow?) GNUS suggestions

[Sudish Joseph <sudish@VNET.IBM.COM>]

I'm now setup at home with a 28.8 link and Linux.  So, all sorts of
bandwidth-related ideas now occur to me (read: netcom's lines suck :-)


* Caching the list of newsgroups locally.  
Setting gnus-read-active-file to 'some solves the speed problem in the
most common case (startup), but it makes it very painful to subscribe
to new/boring-until-now groups.  Setting gnus-save-killed-list to 't
solves this, but makes exit very slow.  I guess what I'm asking is if
it's possible to split the killed list from the .eld file, so that
it's not necessary to read and write such a large chunk of data every
session.  Viewing it as a reduced (w/o article ranges) local copy of
the active file might be better than just calling it a killed list.
Updating this cache when we see new groups (gnus-check-new-newsgroups
is 'ask-server, of course) would keep things very neat.


* Defering splitting of mail in nnml groups to group entry.  
This isn't related to bandwidth in any way, but I might as well bring
it up here.  The actual speed hit in nnml is in the writing of the
articles to individual files, not in the nov file generation.  So,
just spooling all articles to one file per nnml group that would be
split into separate files upon group selection would be neat.  This
would still allow for nov generation at split time.  At OSU, I was on
the perl-porters mailing list, a very high-volume list.  I mention OSU
only because our NFS setup sucked so hard speedwise.  Which meant that
I had to sit through a long split session for that one list every time
I fired up gnus, even though I read that list once a week or so.  This
was one of the main reasons I stuck with asynchronous mail delivery.
I think this, or having nnfolder with nov, would be a very cool option
for people with NFS mounted home directories.  Note that there isn't
much difference between what I describe above and having nnfolder use
nov--the only difference is that we do an extra split at group entry
time.  Now that I have a local ext2 filesys to spool to, asynch
splitting isn't worth the trouble to me and I also get to use sexps to
describe my splitting, instead of procmails tortuous syntax, but I
think it's important that GNUS makes things better for people with
slow writes to their home directory--which covers a lot of people in
larger universities, I'd say.


* Prefetching of articles in the next group.
The nntp-async stuff is a real godsend for dialup lines--once you've
waited for that first article, subsequent articles are quick to
select.  It'd be nice to extend this to work across group boundaries.
Also, I think the current async stuff doesn't handle the case where
you go back and read an earlier article in the group too well.  Even
though that article is in the async buffer, it seems to refetch it.


* Some way to force GNUS to drop all active tcp connections to the
  NNTP server and open them anew.
I'm using diald to manage my connections.  While gnus uses a fresh
connection for articles in a group, it maintains the "control"
connection (the connection used for switching groups, etc.).  This
means that if diald drops my line due to inactivity and then fires it
up again, the control connection is invalid since I have a new IP
address.  A command in the group buffer to force GNUS to re-open the
control connection, while maintaining current state info, would be
very useful.  I'm not suggesting we go to the extreme of http, reusing
existing connections is much better, IMO, except when the connection
itself is invalid (there's no way for gnus to determine when the
connection is invalid, so it has to be a user command).


* Incremental/asynchronous group entry.
This one is much harder, and probably should be left until Lars has
cycled through all the colors in the rainbow :-) It has also been
discussed before.  Presently, upon entering a large group, I wait for
a longish bit as the headers get sucked in (all hail the great god
XOVER, without whose intervention life would be a void) and then for a
shorter, but still significant, period while gnus prepares the
summary.  Incremental threading and summary generation (ugly thought,
but GNUS does most of the required magic already when you fetch a
parent article) would make a huge difference.  As I see it, the only
real obstacle here is in the thread and sorting code--sorting thread
roots while _incrementaly updating_ threads seems difficult to me.  I
would happily forgo sorting if I could hit SPC on a newsgroup and
enter it immediately.  This won't be such an attractive option for
peple with bad newsfeeds, since article numbers will be badly skewed
w.r.t posting date (IBM's newsfeed often gets articles 14-15 days
after they're posted, this makes sorting by date a necessity :( ).
I'm willing to bet that quite a few would prefer faster group entry to
sorting.  Netscape does asynchronous threading, if you haven't checked
it out.


-- 
Sudish