Bill!
And after I just bad mouthed you! So first I offer my heartfelt apology.
:-)
Also sorry for cross posting, I suggest we keep this discussion in one
place, James-dev is quite quiet.
You wrote:
> We did some of this. We separated the pieces of JavaMail into the
> core API piece and the protocol provider pieces. That allows you
> to pick just the pieces you need.
Yep this is true, there's an API and a Reference Implementation.
And it does allow developers to add new protocols and MIME types.
> But we haven't considered carving the core API piece into multiple
> pieces. And we wouldn't consider doing anything of that sort that
> would break compatibility with the existing API.
I certainly wouldn't expect you to, but I hope I can convince you that
there's a middle ground where we can all benefit.
> If you think some great advantage could be had by splitting the APIs in
> this way, tell me more.
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.
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.
d.
***************************************************************************
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 viruses.
**************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
