Re: building a smarter gnus

[prj@po.cwru.edu (Paul Jarc)]

Wes Hardaker <wes@hardakers.net> wrote:
> 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).

Do you mean nnXX-retrieve-headers?

> Wouldn't it be more efficient to maybe pass it a compressed list
> instead and say "retrieve anything from this range"?

According to the manual, backends are already *encouraged* to support
that in nnchoke-retrieve-headers, but Gnus doesn't take advantage of
it because not all backends *do* support it yet.

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

It should indeed be a separate function, I think.  That's the most
convenient way for the backend to express that it's capable of
handling ranges.

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

That isn't a problem.  It's already ok for backends to fail to provide
headers for requested articles that don't exist, AFAICT, so it's ok
for Gnus to request headers for too many articles.


paul