Re: Why article numbers?

[Simon Josefsson <jas@extundo.com>]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> How would you handle two messages with the same message-id?  Or no
>> message-id (think drafts)?  Since it is possible to create that
>> scenario, Gnus should IMHO handle it.  I think an abstract data type
>> separated from the message itself is more flexible.  I see two
>> problems with the use of integers today: handling sets of integers can
>> be slow, and the integer limit in emacs is too small.
>
> Do you think dealing with a set of 1,000,000 integers is slower than
> dealing with a set of 1,000,000 strings, say?

I don't know, but I suspect not.

> For the integer limit, well, err, somebody should do bignums in Emacs
> Lisp :-)

Yes, please. :-)

>> Regarding the nnimap issue, a better solution would IMHO be to fix it
>> to do proper re-syncing on UIDVALIDITY changes, which it probably
>> would have to do even if message-id's are used to index articles since
>> IMAP uses integers to retrieve articles anyway.
>
> Is this possible?

To fix it?  The situation is detected now (but ignored).  What would
be required to make it work, would be to wipe out the gnus info for
that group and replace it with new data from the server.  If the agent
is used, the NOV cache and .agentview and cached articles must be
removed too.  As for cached articles, I'm not sure to handle them --
removing locally cached articles might be a bad idea since the user
might want to keep them.  Gnus-specific flags (i.e., bookmarks) simply
would have to be dropped unless some more information (like
message-id) about the marked articles were available to search for its
new article number.  It is a lot of work, and no backend interface to
do it so nnimap would have to contain even more Gnus internal
knowledge.  Fortunately, people rarely send bug reports about this (I
can rememeber <5 times this was the real cause of a problem) so either
it isn't that important or people give up Gnus for some other client
and doesn't tell us.