Jason, Some links you might find useful:
http://javamaildir.sourceforge.net/ http://bluezoo.org/knife/ http://www.gnu.org/software/classpathx/ Steve > -----Original Message----- > From: Jason Webb [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 04, 2003 9:07 AM > To: 'James Developers List' > Subject: RE: IMAP Development Pointers > > > I shall have a think then (and set about doing it) > DJB's site has a good explanation on how maildir works > http://qmail.plig.org/man/man5/maildir.html > > -- Jason > > > > -----Original Message----- > > From: Edward Flick [mailto:[EMAIL PROTECTED] > > Sent: 04 September 2003 15:24 > > To: James Developers List > > Subject: RE: IMAP Development Pointers > > > > > > Yeah, maildirs seem pretty effective as a store. Thats > > actually what I was hinting at (with a link file instead of > > real links as this is a java program and will be running on > > platforms which don't support real links). I don't buy into > > the idea that creating multiple files will cause much more > > disk thrashing, as a spool file can be scattered all of over > > the drive too. Although, the open/close efficiency issue is > > real, BUT I think this can be counteracted with a good > > full-text index file. Also, thanks to the newer journaling > > file systems, it would be a lot easier to guarantee that a > > message is uncorrupted. Although, I definetely think the > > indexing system should be implemented after a simple maildir > > implementation is put into place. Anyways, this would just be > > a step to at least get this into something close to a beta > > phase. What do you guys think? > > > > -----Original Message----- > > From: Jason Webb [mailto:[EMAIL PROTECTED] > > Sent: Thursday, September 04, 2003 3:02 AM > > To: 'James Developers List' > > Subject: RE: IMAP Development Pointers > > > > > > If there is enough interest or need I will write a > > maildir-style repository. This is used by qmail and > > Courier-IMAP to great effect and provides folders etc., and > > it's safe(ish) over networked file systems. The current > > repositories are less than ideal other than for folder based > > storage ,particularly the mbox one ;) > > > > -----Original Message----- > > From: Jim Wright [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, September 03, 2003 5:40 PM > > To: James Developers List > > Subject: Re: IMAP Development Pointers > > > > > > Hi Edward, > > > > I have University of Washington IMAP on my Linux machine > > and use an experimental format mx which is as you describe. > To quote > > the docs: > > > > . mx This is an experimental format, and may be removed > in a future > > release. ... > > > > [snip] > > > > mx is somewhat inefficient; the entire directory must be read > > and each file stat()'d. We found it intolerable for a > > moderate sized mailbox (2000 messages) and have more or less > > abandoned it. > > > > [snip] > > > > > > There's a general reason why file/message formats are a > bad idea. > > Just about every filesystem in existance serializes file > > creation and > > deletions because these manipulate the free space map. > > This turns out > > to be an enormous problem when you start > > creating/deleting more than a > > few messages per second; you spend all your time > thrashing in the > > filesystem. > > > > It is also extremely slow to do a text search through a > > file/message format mailbox. All of those open()s and > > close()s really > > add up to major filesystem thrashing. > > > > I was not completely convinced by this. File system devices > > are getting faster for a start. > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
