Hi, > be read by other toosl, I don't think that there is a place to preserve the > meta-data from the Mail object (but we can check).
As far as Maildir goes, there isn't, from what I can tell. > make it a requirement to support special stores for spam and error that > preserve the associated mail objects, I think that'll be OK. So what are we saying here 1. We have two interfaces for mail stores. 2. We could retain/enhance the MailRepository interface and write an implementation which wraps around JavaMail stores? This would give us access to "special stores" and JavaMail stores but JM stores would not persist the message meta-data and we would not be adopting a new standard interface. 3. We extend the JavaMail Folder interface to add support for our Mail objects, but I am not sure how clean this is.. How important is the requirement to persist the message meta-data to disk once processing is over? Sergei ----- Original Message ----- From: "Noel J. Bergman" <[EMAIL PROTECTED]> To: "James Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, February 05, 2003 12:10 AM Subject: RE: JavaMail as the message store > Danny, > > You raise a good question. Attributes were, in my understanding, supposed > to be stored on the Mail objects. MimeMessage objects would not be touched. > For something like mbox or maildir, which are standard formats that need to > be read by other toosl, I don't think that there is a place to preserve the > meta-data from the Mail object (but we can check). > > During processing it is a non-issue beause the mail objects will be > persistent in the spool, and will preserve that information. If we want to > make it a requirement to support special stores for spam and error that > preserve the associated mail objects, I think that'll be OK. > > --- Noel > > > --------------------------------------------------------------------- > 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]
