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.
Bill
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
