I'm currently looking at changing the way repositories work for the IMAP
implementation and I do plan to add size (amongst other things) as this
means I don't have to do evil tricks to work out how much is in a
repository. I'm also going to see if I gain benefits from using Java 1.4 NIO
rather than the current crude <= 1.3 IO system.


This won't affect how MailImpl works as it is up to the "user" of a given
repository scheme to decide what they want to store where. We also have to
be careful so that we don't damage other implementations that take a more
simplistic view of life (mbox and possibly Maildir)

-- Jason

> -----Original Message-----
> From: Stefano Bagnara [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
> Sent: 20 April 2005 11:39
> To: 'James Developers List'
> Subject: MailRepository operations, Envelope/Mail separation (was: Re:
> JDBC Repository - Thoughts)
> 
> > I think in fact what happens is that all of the messages are
> > eagerly loaded right after the client successfully
> > authenticates (in the PASS command).  POP3Handler.doPass()
> > calls POP3Handler.stat(), which loads all of the messages in
> > the mailbox into an ArrayList.  And yes, stat() does this by
> > executing one query per message:
> 
> POP3Handler could be changed to lazy-load messages (MailImpl) only where a
> RETR or a TOP is done but we should change the MailRepository interface to
> provide the message size without loading the message itself with further
> query.
> 
> I think this should be taken in consideration while refactoring the
> MailImpl
> thing so to split the Envelope object from its content (Mail) and let us
> to
> move around envelopes without moving the real (possibly big) Mail object
> around.
> 
> I can't rememeber where I read about this idea but I think that this could
> really improve all the spooling operations and also would simplify the
> file/dbfile/db stuff because we would have MailRepository and
> EnvelopeRepository in their File and JDBC implementations only (current
> DBFile would be replaced by JDBCEnvelopeRepository + FileMailRepository)
> 
> MailRepository's should allow separate header-body loading and body should
> be loaded lazily so to use less memory in matcher/mailet that only needs
> to
> match "Envelope"+"MailHeader" stuff and not full content matching.
> 
> Stefano
> 
> 
> ---------------------------------------------------------------------
> 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