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]