[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Braindump: Extended MH Format

From: Chad Walstrom
Subject: Re: [Nmh-workers] Braindump: Extended MH Format
Date: Sat, 11 Dec 2004 01:00:56 -0600
User-agent: Mutt/1.5.6+20040722i

address@hidden wrote:
> Snip various. I'm afraid I've lost track of what the actual problem
> you're trying to solve is; can you reexplain, please?

I did forewarn you with the subject titled, "Braindump".  In any case,
the ideas that spewed out on to this list originated from trying to
incorporate some safer locking mechanisms for MH mail and preventing
IMAP servers (or clients) from loosing track of the emails in the
filesystem because of a folder re-sort, regardless of whether they
participate in using common meta-data files.

OK, just to bring RFC 2060 [ Unique Identifier (UID) Message
Attribute]into discussion:

    Note: Unique identifiers MUST be strictly ascending in the mailbox
    at all times.  If the physical message store is re-ordered by a
    non-IMAP agent, this requires that the unique identifiers in the
    mailbox be regenerated,...
shell$ sortm -textfield subject -limit 4 +inbox 
    ...since the former unique identifers are no longer strictly
    ascending as a result of the re-ordering.  Another instance in which
    unique identifiers are regenerated is if the message store has no
    mechanism to store unique identifiers.  Although this specification
    recognizes that this may be unavoidable in certain server
    environments, it STRONGLY ENCOURAGES message store implementation
    techniques that avoid this problem.

Basically, the IMAP server needs to detect new emails and assign them
the next UID in sequence.  Physically re-sorting the directory throws
emails out of sequence with the IMAP's stored sequence.

> (in response to Jerry Peek: all of this is very much pie-in-the-sky as
> far as I'm concerned and I don't think anybody's going to be doing any
> coding in the near future :-))

Yep, Briandump pie (uhmm...).  Coding subject to agreement on whether
this is at all necessary.  So far, nothing I've proposed is convincingly
"better" than the Maildir file format.  In fact, Maildir is designed
specifically for IMAP ala qmail.  Hard to beat DJB's optimizations in
this context.  But I'm not proposing to solve ALL of the problems that
Maildir solves for IMAP, just locking and tracking of the actual emails.

I agree with you, Jerry, that changing the file names of email is a BIG
change, albeit a "simple" one.  It would touch everything.  I don't know
if it would be enough for IMAP server maintainers to say, "We need to
support this."

Arguably, the .overview and other caching meta-data file might benefit
from having a semi-permanent filename to refer to rather than one as
volatile as we currently use.  It doesn't change the fact that you'll
still be able to use grep and family to access the data.

Anyway, pie.

Chad Walstrom <address@hidden>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]