james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Webb" ...@inovem.com>
Subject RE: IMAP Development Pointers
Date Thu, 04 Sep 2003 16:41:18 GMT
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:eddy@cdf-imaging.com] 
> 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:sshort@postx.com]
> 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: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
> > >
> > >
> >
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-dev-help@james.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 
> 



---------------------------------------------------------------------
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