building a smarter gnus

[Wes Hardaker <wes@hardakers.net>]

half of the speed problems associated with gnus derive from the fact
that gnus uses entire lists of articles when requesting stuff from the
lower ranges.

From what I've gathered (I've started implementing a nnsourceforge
component, which is functionally working but slow), article lists
passed to nnXX-request-articles are always a fully expanded list
(which is causes memory and speed problems).  Wouldn't it be more
efficient to maybe pass it a compressed list instead and say "retrieve
anything from this range"?  nnimap, for instance, I think checks every
article in the list passed to it which causes problems if there are
articles which don't exist anymore.  my nnsourceforge backend is full
of holes, since I'm hoping to use the bug tracking number as the
article id:

  4        273006: blah                           020328
           ^^^^^^
           max - min

So, I don't think it would be hard to create a new function called
"nnXX-request-ranged-articles" which could accept a range instead.  If
the function didn't exist, then fall back to the one that only accepts
an expanded list.

Of course, I really don't know what I'm talking about and I'm just
about nnoo'ed in the head at this point.

Functionally, I want to write a nnXX-request-articles function that is
not passed a list of 273006 articles.  Rather I want to be passed
(226228 . 536386) or something.  I can fill in the holes much more
quickly and using less memory space.  It looks like this isn't
possible right now?

(in part because nnxx-request-group must only return num, max and min
without a valid range list?)

-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."