james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danny Angus <Danny_An...@slc.co.uk>
Subject Re: Let's just tell Sun to rewrite the JavaMail API. Was: What about IMAP support?
Date Wed, 12 Nov 2003 09:59:40 GMT


> But, to some extent, it's a matter of taste.

I completely agree.
JavaMail, like James, is a quiet success, there is very much more
untroubled use of the product than action on the develpment front. This is
for us and I assume for you, a strong indicator that you're doing the right
thing, and that in turn leads to being cautious about change for change's

I understand and respect your reasoning about interfaces vs classes, in
particular when you consider that JavaMail is targeted as an end-user
product rather than a framework specification API. Perhaps this is where
the confusion arises, we, James, need a generic mail framework API and your
users need a specific mail client API. What happens is that on the one hand
we don't want to re-invent the wheel in terms of the basic entities of Mail
(addresses/messages/Mime etc) but on the other it is difficult to use just
those parts of JavaMail, there is no no-args constructor for MimeMessage
for instance.

I'm also well aware of the large quantity of RFC compliance code which is
encapsulated in JavaMail, and the horrors of dealing fully with Mime type
Multipart/*. For this alone we should be thankful for your hard work.

However I also believe that JavaMail has reached a level of uptake and
stablility that will by necessity restrict the extent of changes you can
make, and I'd encourage you to at least keep us in your mind when looking
at the future of JavaMail.

> Designing classes for effective subclassing is still a challenge, and
> we're still learing how to do this well.  I think you'll find that you
> can subclass MimeMessage and pretty much make it do whatever you want,
> especially if you don't need to leverage the implementation within the
> MimeMessage class itself.

I agree.

> I'd be happy to talk about specifics, but again with the following
> - It has to remain compatible
> - We're resource limited, so any change will not happen soon
> - Any change has to actually *be* better, not just look better
> - Can't compromise the client programming model

> So let me know what problems you're running in to.

That's nice to know, and appreciated. I've outlined my thoughts about
MimeMessage.saveChanges() for you to look at as an example.
I'd be more interested in hearing whether this kind of suggestion is
acceptable in principle, than in actually seeing it implemented in the near

If this kind of thing is acceptable I'd be much happier to work on removing
some of James proprietary classes in favour of API ones knowing that well
thought out compromises to issues encoutered would be likely to receive
fair consideration.

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(){

which would sucessfully preserve your contract, our clock cycles, and the
inheritance of Message et-al.

> The challenge comes in "slightly modifying"
> the existing behavior/implementation to provide some added value.

Yep, I can see that!



The information in this e-mail is confidential and for use by the addressee(s) only. If you
are not the intended recipient (or responsible for delivery of the message to the intended
recipient) please notify us immediately on 0141 306 2050 and delete the message from your
computer. You may not copy or forward it or use or disclose its contents to any other person.
As Internet communications are capable of data corruption Student Loans Company Limited does
not accept any  responsibility for changes made to this message after it was sent. For this
reason it may be inappropriate to rely on advice or opinions contained in an e-mail without
obtaining written confirmation of it. Neither Student Loans Company Limited or the sender
accepts any liability or responsibility for viruses as it is your responsibility to scan attachments
(if any). Opinions and views expressed in this e-mail are those of the sender and may not
reflect the opinions and views of The Student Loans Company Limited.

This footnote also confirms that this email message has been swept for the presence of computer


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message