From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/8740 Path: main.gmane.org!not-for-mail From: David Moore Newsgroups: gmane.emacs.gnus.general Subject: Re: IMAP problems. Date: 11 Nov 1996 14:15:14 -0800 Sender: dmoore@sdnp5.ucsd.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035148866 14103 80.91.224.250 (20 Oct 2002 21:21:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:21:06 +0000 (UTC) Return-Path: Original-Received: (qmail 29948 invoked from smtpd); 11 Nov 1996 22:40:16 -0000 Original-Received: from ifi.uio.no (0@129.240.64.2) by deanna.miranova.com with SMTP; 11 Nov 1996 22:40:15 -0000 Original-Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 11 Nov 1996 23:16:21 +0100 Original-Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by UCSD.EDU (8.8.2/8.6.9) with SMTP id OAA04324 for ; Mon, 11 Nov 1996 14:16:19 -0800 (PST) Original-Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4) id OAA19898; Mon, 11 Nov 1996 14:15:15 -0800 Original-To: "(ding) Gnus Mailing List" In-Reply-To: visigoth@naiad.fac.cs.cmu.edu's message of 11 Nov 1996 10:21:15 -0500 Original-Lines: 53 X-Mailer: Red Gnus v0.60/XEmacs 19.14 Xref: main.gmane.org gmane.emacs.gnus.general:8740 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:8740 > 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 | Computer Systems Lab __o UCSD Dept. Computer Science - 0114 | Work: (619) 534-8604 _ \<,_ La Jolla, CA 92093-0114 | Fax: (619) 534-1445 (_)/ (_) | Solo Furnace Creek 508 -- 1996!