james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: ID-mail
Date Sat, 08 Mar 2003 05:05:59 GMT
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: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org


Mime
View raw message