On Tue, Jan 18, 2000 at 12:53:37AM -0500, Russell Nelson wrote:
> > Um, am I missing something? I thought the whole point of the "info"
> > portion of the filename of the message in the maildir?
> Right, and do you want the filename changing all the time? Instead of
> a simple "open()", you have to do a "opendir(), readdir(), string match,
> closedir()" set of syscalls. I suppose that you could attempt a
> simple open() first, and then only if that fails do you go searching.
I saw that from another message. Valid point. Perhaps the server would
treat the observed filenames as a "cache" mapped by the unchanging
portion. Any miss would cause a revalidation of all of them (since
readdir typically issues only one syscall per many directory entries).
This is basically what you described.
I don't very much favor the idea of extending the Maildir structure just
to add flags like that. On the other hand, such extensions are ideal
for storing other persistent client (configuration) data.
On the subject of extensions of Maildir, though, I had a bit of a
radical thought: make each message a directory, containing one file for
the headers, and one file per attachment. This has the benefit of
pre-parsing attachments for processes like IMAP that want to be able to
fetch just one of the parts, but at a significant cost. Fetching the
entire message would cause quite a bit of conversion and repackaging.
Searching now touches even more files. Every message now uses at least
3 inodes now instead of just one, with the side effect of increasing the
amount of wasted (slack) space. More disk accesses to examine a
mailbox.
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
