> > make it a requirement to support special stores for spam and error that
> > preserve the associated mail objects, I think that'll be OK.
> 2. We could retain/enhance the MailRepository interface and write an
implementation which wraps around JavaMail stores?
As Serge pointed out, to do IMAP (for example) properly we would need to turn
MailRepository into the store and folder abstractions from JavaMail. The only issue
seems to be preserving meta-data in certain situations, and after more thought I have
come up with several solutions.
> How important is the requirement to persist the message meta-data
> to disk once processing is over?
I don't think that it matters except for someone wanting to see why a message turned
up in the error or spam folders, or wanting to re-spool such a message.
There are several possibilities. One that I am starting to lean towards is a
convention for ToRepository to store the message in the folder, and the meta-data in a
special .META-DATA/ subfolder. That ought to work with any store implementation that
supports subfolders.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
