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.
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.
Rich Hammer Hillsborough, N.C. mailscreen.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
