Re: IMAP problems.

[David Moore <dmoore@UCSD.EDU>]

> 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?

	As long as they are always increasing, logically things will
work with subtracting an offset.  I also suspect that converting the
UID's will not be too expensive, since you will probably have to do
other cleanup on the incoming data anyways.

	When the message numbers come in, you could just stick a space
character before the 5th digit from the right hand edge of the number,
then use read to load both of these numbers (if there are less than 5
digits, just do 1 read).  The first (left hand) number is always between
0-42949, and the second is always between 0-99999, which are both
representable in emacs.  Subtract your initial number from these pair
wise and multiple the first by 10000.  Then just stuff that value back
into the buffer.


Initial number is 123432 -->  keep: (1 23431)  ;; make first message #1

When you get: 137563	-->  (1 37563) - (1 23432) = (0 14131)
			-->  new value: 14131


Of course, it might just be faster to stick a .0 on the end of the
number, read it as a float, do a float subtraction and convert back to
an integer.  The overhead of simple floating point operations isn't as
large in emacs as in other languages, due to the large constant overhead
of the interpreter.

	And I suspect that the cost of mangling won't be that noticable
in current gnus, due to high costs elsewhere in NOV processing.


-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | Solo Furnace Creek 508 -- 1996!