expiry with holes in groups

expiry with holes in groups

[Kai Grossjohann]

Hi there,

suppose I've got holes in my groups, eg article no. 23 is ticked, then
come many many already expired articles (which aren't on my disk any
more), then article 4711 upwards exist again.  Then, Gnus will look
for the date of each article number between 23 and 4711 whether or not
it is older than the expiration time.

Is this a backend issue (using my own homegrown backend) or is there a
general optimization that can be used?

kai
-- 
I wonder why nobody don't like me,
or is it de fact dat I'm ugly? -- Harry Belafonte

Re: expiry with holes in groups

[Lars Magne Ingebrigtsen]

Kai Grossjohann <grossjohann@ls6.informatik.uni-dortmund.de> writes:

> suppose I've got holes in my groups, eg article no. 23 is ticked, then
> come many many already expired articles (which aren't on my disk any
> more), then article 4711 upwards exist again.  Then, Gnus will look
> for the date of each article number between 23 and 4711 whether or not
> it is older than the expiration time.

Well, if you're using total-expire, then Gnus will probably send the
entire list of articles between 23 and 4711 to be expired.  If you
(the backend) knows that those articles don't exist, then you can just
ignore those articles.

The problem here is that Gnus doesn't know which articles exist in
each group; it only knows the MIN and MAX active articles.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen