Re: building a smarter gnus

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

Wes Hardaker <wes@hardakers.net> writes:

> 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). 

As previously noted, that would be nice, and was something I thought
should be in the back end interface design.

However, it's never really been followed up, and just putting ranges
in the back end interface wouldn't really help all that much.  For
instance, when entering a group, Gnus uses a list of article numbers
in the summary buffer for doing various things, so we already have
the list, and it's probably the same list that's passed to the back
ends.

And there would probably have to be written range iterators --

(dorange (article ranges)
  ...)

And a memq on a list of integers is much, much faster than
`gnus-member-of-range', I think.  So I think it's entirely possible
that any gains one get from not having to uncompress the ranges would
be lost by having the other operations be slower.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen