Re: IMAP problems.

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

David Moore <dmoore@UCSD.EDU> writes:

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

In fact, there's a pass over the input with a string-replace to quote
things properly, followed by a read to get it in--that's how I'm doing
things right now.  I suspect switching from (read) to reading strings
by hand would not speed this up much, but I haven't really checked
into it.

> 	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

I already have some code which turns numbers into (a . b) pairs in the
input stream for reading--I can just adapt that.  (Should've thought
of that in the the first place--was thinking of either that or delta,
but the combo is good.)

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

Well--I'll go with the pair of ints for now, just because it seems a
little cleaner.  We'll see what happens.  I've got a nice little imap
library now, for low-level stuff.  Now I should be able to write the
application layer callbacks for it (read nnimap.el), and we'll have
something that works in not too long.

My former approach was taking IMAP stream and converting it to NNTP
stream, so that Gnus was happy.  I think this approach will work
better.

Like I said, I'll be away for a week now--chances are, there'll be
something that works for IMAP4 (I might try to support older IMAPs
later, but I don't have anything that supports them, and I intend to
rely heavily on UIDs, so...) with a few weeks.

John.