Hi Jason,
Boy and I was thinking about doing it myself, but if you want to I am not
going to stop you, hehe :-P.  Just a note, there should probably be folder
link files too, right?, if you want to be able to have shared message
spaces.  Do you think this is the way to go, also?  I'm just tossing out
ideas, and am open to others.

Ed

-----Original Message-----
From: Jason Webb [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 04, 2003 11: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]

Reply via email to