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 Fri, 14 Nov 2003 19:07:10 GMT
Richard O. Hammer wrote:
> I want to add a few observations to what Danny has already said in this 
> thread.  I mention two classes, Message and Transport, which I think 
> could be improved by being super-classed, by giving each of them a 
> simpler parent.  But this is based upon my limited experience with using 
> JavaMail's API for developing a mail server.  So my list is probably not 
> complete.  This may be just a sample.
> First, obviously, in a mail server I need an object to represent a 
> message.  Since it might require a lot of work for me to develop the 
> code myself, I look hopefully in JavaMail.  There I find Message and its 
> descendant MimeMessage.  These have many great methods which I can use, 
> already written.  But Message has more than I need in some ways too.  It 
> has a Session and a Folder, objects which I don't think I need in a 
> server, and it is difficult for me to construct a Message without 
> supplying a Session or Folder.
> Now I guess it is true, as was suggested earlier, that I could get the 
> functionality I want by subclassing Message (or MimeMessage) and 
> supplying empty stubs for any objects (such as Session or Folder) which 
> it wants but that I don't need.  But this seems backwards given my 
> understanding of object-oriented design.  It seems to me that Message 
> ought to have an ancestor, perhaps named GenericMessage, useful in both 
> clients and servers, which would contain the wonderful methods needed in 
> both clients and servers, but would not contain a Session or a Folder.  
> The Session and Folder should be added in a subclass for clients.

Messages without Folders are common.  Having Message know about the
Folder it came from is a convenience.  Rather than have people learn
about two concepts (messge within a folder and message outside a folder),
and their "internet" equivalents, we get by with one concept.

A Session is simply a place to store configuration information for
JavaMail, rather than having it be global.  MimeMessage uses this
information in a few places (although it's not quite as "optional"
as perhaps it should be), and most importantly it enables the simple
Transport.send method to find the appropriate Transport object to use.
If you never use Transport.send or Message.reply, you should be able
to get by with a null Session.  Or, you could create a single global
Session object and use it everywhere JavaMail needs a Session object.
Actually, that's what Session.getDefaultInstance is for!

> Another class which does more than I want is Transport. 
> Transport.sendMessage() sure is a handy method.  It takes many problems 
> off the shoulders of developers.  It is used in James, even though I 
> understand it was intended only for clients.  But it gives a problem to 
> server developers as it sets message headers in ways appropriate for 
> clients -- but not appropriate for servers.  Here again it seems to me 
> that Transport could descend from a class which did less.  If there were 
> a GenericTransport class which did not set message headers, that would 
> be a boon to server developers.

I'm not sure what you're referring to.  Transport.sendMessage is an
abstract method so it does nothing.  SMTPTransport.sendMessage doesn't
set any headers itself.  Perhaps you're concerned about the headers
that are set in MimeMessage.updateHeaders?

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

View raw message