One detailed reason I find MimeMessage less than ideal is that Message contains the method saveChanges(), and Method.saveChanges() re-writes the Message-ID header. James wastes clock cycles saving and restoring Message-ID when message contents change. Surely it is more efficient for saveChanges() to not do this, and for specialisations of this class to override it and add that behaviour, resulting in only those applications which require the action having the overhead of performing it?
The alternative, the compromise position I'd like to propose is this:
Message.saveChanges() remains unchanged, but internally the action is carried out by calling two methods, actionMimeChanges(), which would check and correct the Mime headers (like content transfer encoding and the Mime version header) and do any persisting which might be required and updateMessageID() (Perhaps this is already the case? I haven't ever read your code in great detail, partly from fear of plaigerising it!) then if storeChanges() is exposed as a protected method a subclass of MimeMessage can override saveChanges more elegantly like:
public void saveChanges(){ super.actionMimeChanges(); }
which would sucessfully preserve your contract, our clock cycles, and the inheritance of Message et-al.
This is worth considering for the next JavaMail API revision.
How about something like this...
Currently MimeMessage.saveChanges calls MimeMessage.updateHeaders, which (among other things) calls setHeader to set a new Message-ID header. It would be easy to move that setHeader call into a new protected updateMessageID method. That should give your subclass of MimeMessage an easier way to control updating of the Message-ID header.
This does point out another workaround with the current implementation. You can override the setHeader method and only allow setting the Message-ID header if it's not already set.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
