Noel J. Bergman wrote:
Basically I mean to suggest that we take the existing file and database repositories, and rework/add necessary methods to make them implement the JavaMail javax.mail.Folder (maybe also implement javax.mail.Store). I think this is a good idea for the following reasons:Serge suggested JavaMail as the message stores interface. I'm not sure what the performance is, but we do have the JavaMaildir author to help out, and I'm sure that he is familiar with the performance.
1. familiarity because it's a standard API
2. makes our store implementations more re-usable (our Store implementation could be bundled as a separate jar to let a servlet app access the database store)
3. makes it easier to drop in other mail store implementations
and more importantly...
4. If you look at the functionality/methods we need to add to our existing mail repository interface to let it support NNTP and IMAP, you basically have javax.mail.Folder.
Agreed... spools require the Mail object, and there's the whole spooling logic itself which most mail repositories don't need, and there's the desire to have that implemented separately.Also, please note that we're not considering JavaMail for the spool. The spooler needs to be high performance, but it will only move the Mail object, which have a looser reference to the MimeMessage. The MimeMessage wouldn't move as much as it does in the current scheme, cutting down on that overhead.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com/
p. 1.301.656.5501
e. [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
