Bill, >From what I can see, the JavaMail package is mostly policy neutral. The only policy that I see enforced by JavaMail code outside of a service provider is the one that changes the Message-ID every time you call saveChanges.
That could be addressed by implementing a MimeMessage subclass, but we still want to expose a common means for application control over when a new Message-ID is assigned. An application-specific, ad hoc, subclass doesn't provide a uniform approach to exposing this policy to the application domain. With respect to mutability semantics, the javadoc for Message.saveChanges() mentions only READ_ONLY folders as not allowing saveChanges(). Other changes are prohibited when calling mutators by IllegalWriteException. Sorry, you're right; I should have caught that exception, too, in my off-the-cuff example. My example was predicated upon a local, mutatable, message store, not a provider for POP3 or IMAP, which I would not expect to allow operations that aren't supported by the protocol (nor do they). I would have to revisit the implementations of mh, maildir and mbox, but even if they don't currently allow in-store changes that doesn't define the semantic. Local message stores could (probably should) permit message mutability, and the javadocs don't imply otherwise. There are obvious usage examples for why one might want to change the message. Whether or not that results in a new Message-ID is a *policy*. However, JavaMail does not currently expose an API by which to control that policy, so how would a service provider that wanted to expose control do so in a clean manner? > Some people argue vehemently that as a matter of principle > you should not be able to change a message once it's stored > in a mailbox. They are entitled to that view, and to operate that way within their local domain. It is clear, however, from the RFC that there are allowable changes to a message that do not require a change to its identity. This is a matter of policy, not a universal mandate. Shared frameworks like JavaMail should enable, not preclude, policy choices. The policy is reasonably within the province, for example, of the service provider implementation, where it could be dictated by necessity or configured policy, but we still need a means for the application to state its intent. For example, Serge mentions http://bugzilla.mozilla.org/show_bug.cgi?id=2920. The opinion of the Mozilla developers is different from that of the Outlook developers. The feature missing from Mozilla is present in Outlook, and I use it from time to time. Again, this is a policy issue, and the JavaMail API should provide control over policy. The automatic detection approach was second best in my mind for a variety of reasons, so discarding it is fine with me. I wasn't suggesting that you introduce saveChanges(Boolean) in Message. It would be a method on MimeMessage; for the person who knows what and why. The new method, be it saveChanges(Boolean) or saveChangesKeepMessageID() (and, no I am not serious about the method name) would be backwards compatible and implementing an explicit suppression semantic minimizes any risk. Not sure what issue you see with respect to setting the Content-Type header on behalf of the user. It ought to be set based upon what changes were made, so I don't see that as a problem. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
