Re: Backend writing

[Simon Josefsson <jas@extundo.com>]

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

> Simon Josefsson <jas@extundo.com> writes:
>> I think nnmaildir is different though, don't you hide the renumbering
>> from Gnus (by translating back and forth between old and new
>> numbering)?
> 
> I have external, non-numeric article identifications that never change
> for a given article during its lifetime.  Gnus never sees those; I
> translate them to article numbers.  That mapping does change from one
> Gnus session to another, to keep the numbers small and consecutive.

Oh!  How do the cache/agent like this?  Maybe the cache/agent isn't
really useful together with nnmaildir though.  But I doubt it would
work, which is sort of bad.  You couldn't have the nnmaildir spool NFS
mounted and use the agent when you don't have network connectivity,
could you?  Do you also frob group info to renumber the marks?  When
do you do this?  Do you use nnchoke-request-update-info?

>> 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...).
> 
> Ah, ok.  So the only IMAP-level identification of an article is
> subject to change during an article's lifetime?  Or is there another,
> non-volatile piece of identification that just isn't used?

No.  The article number in IMAP is intended to not change during the
life-time of an article, but IMAP has a concept of UIDVALIDITY so
clients can find out if there has been a renumbering.  The client must
then delete all cached copies of the article.  Most server never
change uidvalidity unless something major happens, but some have a
more liberal interpretation..