Re: Backend writing

[Simon Josefsson <jas@extundo.com>]

prj@po.cwru.edu (Paul Jarc) writes:

> Simon Josefsson <jas@extundo.com> writes:
>> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>>> But haven't you just changed nnimap to ignore article renumberings?  I
>>> suppose you wouldn't do that unless it's safe?
>> 
>> I don't know if it's safe, that's what Oort is for. <g>
> 
> FWIW, nnmaildir has been renumbering articles each time you open the
> server since 2001-04-11.  No problems yet.  But you seem to be dealing
> with something that changes more frequently than that, right?

Depends, some IMAP server seem to change the UIDVALIDITY value more or
less at will (UIDVALIDITY indicate that a renumbering might have taken
place).  Most don't.  And those that do sometimes doesn't actually
renumber anything, so it just "works" anyway.  The problem is when a
uidvalidity change is actually due to a real renumbering, and even
more problem arise if the renumbering re-use article numbers.  This
kind of IMAP server design is rare though, so in practice I don't
think it's a big problem.

I think nnmaildir is different though, don't you hide the renumbering
from Gnus (by translating back and forth between old and new
numbering)?  Nnimap doesn't, it simply present the servers article
numbers to Gnus and hopes for the best.  (And assuming uidvalidity
doesn't change, the IMAP design guarantee that Gnus will be happy.
Problem is when uidvalidity change...).

>> Basicly, nnimap makes sure the old NOV cache isn't used when a
>> uidvalidity has changed.  [...]  It gets sort of ugly if a backend
>> has to update internal things of Gnus's cache and agent.
> 
> Does this mean nnimap is stepping outside the backend interface?

Not this time, nnimap doesn't mess with the cache or agent.  So an
article cached by Gnus might become invalid if a renumbering has
happened.  It would be nice if nnimap could tell the cache/agent to
invalidate everything it knows about stored articles.