At 10:51 AM 9/7/00, Jason L Tibbitts III wrote:
>So you delete message N. Someone (or worse, the digest builder) requests
>message N+5 and ends up getting N+6 because you deleted a message out of
>the archive but the system has no way of knowing that.
That could only happen if I were editing the archives as the builder
was running, no?
>Message numbers are supposed to be _persistent_.
Why? When you use archive-index, you get a number. Asking people to
review the index before they issue a get command seems like a
reasonable compromise between never being able to fix the archives
and always being able to use the same number.
Maybe I'm missing something here - help me understand how the number
is used EXCEPT when it is returned by archive-index and fed to archive-get.
>I don't want to have
>to use Message-IDs (which are not unique, no matter what you might want to
>believe) or an MD5 sum of the article (which has an even worse problem in
>that you can't even edit one character in the article without changing its
Agreed! The alternatives to having an integer are poor. But if the integer
simply represents a sequence number for which msg is in the archive file,
the integer is enough! If I alter the archives (to remove copyrighted
material under the Millenium Copyright Act, for example) I need a way to
re-compute those integers. Once they're re-computed, who's the wiser that
they are not the original integers?
>It's way more complicated than that (you have neglected Content-Length:),
>but yes, we do know how to do it. The problem is not in building the
>index, it's in preserving persistence of article numbers across the changes
>that you might make.
OK, I guess I'm not clear on where the article numbers might be used.
If they're just being typed by humans, they can change frequently. If
they're being used by internal routines, those routines would have to
know to go get new numbers when the archives were re-indexed.
mailto:firstname.lastname@example.org | http://www.climber.org/eckert/
Info on peak climbing email lists mailto:email@example.com
Things change. People change. Things change people.