james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: IMAP Development Pointers
Date Thu, 04 Sep 2003 16:47:12 GMT
Except that you can't use any of those.  Those are GPL licensed.

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

Edward Flick wrote:
> Jeez, I guess searching for a maildir impl would be a lot easier than coding
> your own :-P.  Hehe.
 >
> From: Steve Short [mailto:sshort@postx.com]
> 
> 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:jw@inovem.com]
>>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:eddy@cdf-imaging.com]
>>>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:jw@inovem.com]
>>>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:jimw@paneris.org]
>>>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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message