On Fri, 5 Apr 2002, at 11:23pm, Derek D. Martin wrote:
> For instance, the IMAP server can index the file and cache the results.

  Already done.  Look in the UW-IMAP documentation (I use the term loosely)  
for a format that is basically mbox with a persistant index and per-message
locking.  I *think* it was called MBX, but I could be wrong on that.  This
is the format the UW people favor.

> I'm not so sure about MMIO (seems like it would be a memory hog, but I
> don't really know that much about MMIO, unfortunately).

  MMIO just maps a file into virtual memory.  You can basically think of it
as a transparent wrapper around read() and write() with automatic buffer
allocation.  The details I'm fuzzy on.  :-)

> ... after looking through some of the RFC's, that really just doesn't look
> like fun.

  After looking at any standard, implementation of anything doesn't look
like fun.  :-)  All those less-common and corner-cases you have to handle
take the fun out of things.  Of course, implementations that cut those
corners are usually the same ones sysadmins curse on a daily basis... :-)

>> Basically, mbox sucks.  :-)
> 
> Sure, but the alternatives do too.  They just suck differently.

  Heh.  That applies universally.  :-)

> The trick is initially opening the mail store.  Large Maildir mailboxes
> typically take an order of magnitude longer to open than mbox files ...

  In generally, any storage format that does not keep an index of important
headers is going to suck.  One of the one-file-per-message formats has a
{feature, extension} which keeps a persistant index, which, IMO, is the best
way to handle things.  Message listing is fast, seeking a single message is
fast, deletes are fast, writes are fast, and locking is much easier.  This
method is also closest to the Unix Philosohy.

> Since filesystems on Unix systems tend to minimize fragmentation by design
> ...

  Heh!  You've never seen the fragmentation stats on a busy mailspool, then!

  :-)

-- 
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |



*****************************************************************
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*****************************************************************

Reply via email to