IMAP problems.

[visigoth@naiad.fac.cs.cmu.edu]

Okay.  I just ran into the latest really major problem with Gnus doing
IMAP.  The most convenient thing for Gnus to use as the message number
for these messages is their UID--the problem is, UID (and UIDVALIDITY,
which is a number that's used to verify that the UIDs are the same as
the last time you looked, i.e. the group wasn't moved and then
recreated or something) are defined by the IMAP spec as 32bit
integers.  And, in fact, they -are- 32-bit integers.  And the UIDs
don't start at one, they start higher...  In fact, in my IMAP INBOX
right now, all the UIDs are outside the range of integers that Emacs
can manipulate.

This isn't good.

So--there are a couple of ways I can see of dealing with this.  One is
to squirrel away the UID of the first message of a folder the first
time you look at it--this number would be stored either as a string or
as a float, since neither of these are limited to 32 bit integers.
When a message is fetched or received from the server, the UID is read
as a float or a string and then added/substracted from the "base" UID
that was originally read (UIDs are guaranteed to grow over time.
Usually grow by 1 per message in folder.) depending on whether it's
going out or coming in.

This is kind of icky.  It means that we have to keep an extra number
around for the group (not too hard), and that we need to mangle every
message number as it goes from Emacs <-> IMAP.  If it's a string, we
need to do our own math.  If it's a float, we need to do float math.

Any other ideas about how to deal with this?

John.