Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> danielv at netvision.net.il is claimed by the authorities to have written:
> 
> > Now also added a POP "QUIT" to closing the pop connection, so deleting
> > messages works too.
> Any chance you might be interested in trying to make a decently working
> 'leave messages on server' facility? From RFC 1939 it_looks_ like it
> shouldbe feasible to use a POP-server unique ID to check which messages
> you already have uploaded so they don't get reloaded.

Absolutely.  The UUID command will give you an ID for the messages that
lasts between POP sessions.  Within a session, POP numbers the messages
from 1 to n, but the numbering can change after each login.  UUID will
tell you the UUID's for each of these messages.

To add a proper leave-on-server variation, the main engineering
requirement is that Celeste needs to remember which UUID's it has
already downloaded.

It just occured to me, that you only care about UUID's that are
currently on the server.  Once you delete a message off the server, you
can also delete the UUID from your local list.  Thus, the list you store
locally can be pretty short, so long as you occasionally download and
delete the messages from another client.  It could surely be done by
having an EMAIL.uuid file in the local directory with a list of id's. 
(It would be *nice* to support people who just leave everything in the
in box, but that would just be icing IMHO.)


I have suggested in the past that we should rewrite the index file
mechanism so that you can add extra fields, and so that it loads and
saves much faster.  Then you could start storing the UUID's right in the
index file.  I expect that the speed could be improved by ordering the
index file one field at a time, instead of one message at a time,
because we could probably come up with ways to load long arrays of int's
and long arrays of string's very quickly.  Also, abandoning the text
format is likely to be useful; the robustness of the index file isn't
that important, considering that it can be regenerated from the messages
file.

I still think this is a good long-term thing to do, but it's a fair
amount of work.  Having a separate .uuid file, and adding a
corresponding instance variable to MailDB, should work in the short
term.


Incidentally, Josh Gargus posted a UUID patch for Celeste at one point. 
His code, if I understood it correctly, would scan the whole .messages
file to find which UUID's have been downloaded (note: most POP servers
seem to add a header to the message with the UUID in it.).  This is
unscalable for large email databases, but the rest of the code might be
stealable.


Lex