Re: building a smarter gnus

[Wes Hardaker <wes@hardakers.net>]

>>>>> On Thu, 28 Mar 2002 19:54:33 -0500, prj@po.cwru.edu (Paul Jarc) said:

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

Paul> Do you mean nnXX-retrieve-headers?

Uh, yeah.

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

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

Grr...  You know, I searched for "backend" in the manual and didn't
see anything so just copied an example.  I now see I should have
searched for "back end".  Sigh.

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

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

Yeah, that seems sensible to me.  Now, who's going to implement the
support for doing this :-)

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

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

Right.  But it's inefficient, in my opinion, to request an extremely
large number of articles when only a few exist.

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