Sam [mailto:[EMAIL PROTECTED]] wrote:
> I don't use IMAP and I've looked inside c-client only briefly, on a couple
> of occasions. Currently, it scales to about a 1,000 messages per folder
> or INBOX, before it starts to slow down and eat memory. This is
> reasonable for a webmail CGI, but for full mail services, you'll need to
> scale into hundreds of thousands of messages. I'm considering either
> fixed length records, or GDBM or DB-based indexes.
Okay. Lets assume we've got some kind of database backend for the index file
where we can add, remove, and modify records. How exactly would one keep it in
sync with the Maildir? I guess each time you would have to compare the messages
in the maildir with the messages in the index, and summarize new messages while
deleting old ones. Also detect if a message has changed, and re-read the
summary info. You are handling this with timestamps I assume?
Also, what kind of summary information are you storing? Well, I guess that's
dependant on the app and might be different for c-client.
I don't know if this or any Maildir app could scale to hundreds of thousands of
messages... there is an inherent limitation in Maildir because it stores all of
the messages in the same directory without any kind of hashing. The filesystem
would grind to a halt before you could even deliver a hundred thousand messages
to a maildir, I would think.
(That is unless any UNIX like OS has gotten around to doing any kind of smart
directory implementation that handles large directories. I so badly want to see
someone make the directory index change to a hashed format after about a
thousand files.)
How does your implementation keep the index updated? If you can scale to 1,000
messages, I'll bet that's good enough for most people and it's far better than
plain-old-Maildir. Also, where in your source code is this done?
- David Harris
Principal Engineer, DRH Internet Services
