Depends. The classpathx mbox one was a little brain dead as it loaded all the messages into memory everytime it did something. The current James one does not :)
> -----Original Message----- > From: Edward Flick [mailto:[EMAIL PROTECTED] > Sent: 04 September 2003 17:52 > To: James Developers List > Subject: RE: IMAP Development Pointers > > > Jeez, I guess searching for a maildir impl would be a lot > easier than coding your own :-P. Hehe. > > -----Original Message----- > From: Steve Short [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 04, 2003 11:20 AM > To: James Developers List > Subject: RE: IMAP Development Pointers > > > 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] > > > --------------------------------------------------------------------- > 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]
