james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Shannon <bill.shan...@sun.com>
Subject Re: Let's just tell Sun to rewrite the JavaMail API. Was: What about IMAP support?
Date Wed, 12 Nov 2003 08:02:44 GMT
> I don't believe that it is necessary to split the API per se, but consider
> it this way..
> A mail-client API and a mail-server API would be specialisations of a
> generic mail API.
> The generic API would be composed mainly of interfaces, and implementation
> would be done by the specialisations.
> This is reflects the fundamental principles of OOD.
> What I'd like to see would be for more interfaces and fewer implementations
> in the API itself, so that it could be left to
> the developers of server software to replace Sun's implementation of an
> interface with another implementation who's behaviour is better suited to
> the specialisation.
> MimeMessage is a case where I think we've missed the boat. It is probably
> too entrenched in peoples use of javaMail for it's inheritance to be
> meddled with but as a for-instance...
> MimeMessage should be an interface.
> AbstractMimeMessage should provide the basic functionality of MM, in terms
> of the content type handlers and things.
> ClientMimeMessage would implement MimeMessage but exhibit behaviour
> appropriate in a client application (like the message-ID /saveChanges()
> feature)
> ServerMimeMessage would behave in a way specialised towards the
> requirements of server software.

As you note, we're severely restricted in what we could do here without
breaking compatibility.

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

There are well known tradeoffs between the use of interfaces vs classes,
many of which are described in Chapter 4 of Effective Java.  The use of
interfaces makes it very hard to evolve an API - if you don't get it right
the first time it's very painful to fix it later.  We've taken great
advantage of the fact that the majority of JavaMail APIs are defined by
classes rather than interfaces, this has allowed us to evolve the API
without breaking either applications or protocol providers.  We're
*strongly* committed to compatibility, and yet we know that we're not
good enough to get the API completely correct the first time.  Being able
to evolve the API is critical.

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.  The challenge comes in "slightly modifying"
the existing behavior/implementation to provide some added value.

> I'd like to look at the artificial distinction between Store and Transport,
> and folders and the Session too to see if some meddling with inheritance
> would at least give us the hooks on which we could hang server specialised
> classes so that they would also be JavaMail implementations, I knw we can
> achieve this at the moment, but not without going to some bizarre lengths
> and to some extent loosing sight of the point of the exercise.

I'd be happy to talk about specifics, but again with the following caveats:
- 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.


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

View raw message