On Fri, 14 Jan 2000, Russell Nelson wrote:
> Mikko H�nninen writes:
> > But, the commentary completely misses the good points and the purpose
> > of Maildirs: that they're ideal for incoming mail delivery, especially
> > when the folder is accesses over NFS (whether "access" delivery or
> > reading or both). Maildir format is not something you should be using
> > for email archival, or for very large mail folders. However, the lack
> > of locking requirement is a big win over NFS.
>
> Right, and any scalable email system is going to use NFS. Therefore
> the question in my mind is not "What should be used for large folders
> instead of Maildirs?" but instead "What must be done to make Maildirs
> more efficient"? One way to do that would be for Dan to change the
> Maildir specification so that a Maildir may have multiple "cur"
> directories. Then, keep a CDB containing a subset of the message
> headers.
No need to. Try opening a 1,000 message Maildir with Pine or Netscape
Messenger (Outhouse Excuse would probably work too) connected to
Courier-IMAP. The initial folder open should take less than 10 seconds,
depending upon your hardware. Subsequent folder opens will be almost
instantaneous, and, at there won't be any noticeable delays in browsing
the maildir. And the only thing that Courier-IMAP caches are the UIDs of
each individual message, which is refreshed with a single directory scan.
Pine never asks for headers of every message, and Netscape Messenger
caches the headers by itself. It seems that the original IMAP
implementation by uwimap was so piss-poor performance-wise, that pretty
much all IMAP clients either do some form of caching themselves, or are
very carefull not to issue any IMAP requests that might bog down the
server.
