Daniel F. Savarese wrote:
I think that impression may be based on a different expectation of what the API was originally intended to do. I know you're not looking for an explanation, but for the benefit of onlookiers ... Returning a writer was an efficient way of bypassing Java's terrible (at the time) memory management and allowing large amounts of data (i.e., many megabytes as in attachments) to be written to a stream without buffering it all. The package was never intended to model email messages or provide all the hooks of JAF, hence the C-like approach in this case of "here's a stream, write your data to it." It's clear that people who look at the library today want higher level functionality and that will have to be accommodated in any future redesign. Also, with GHz processors, GB memories, and fast JITs, better OO designs that were woefully inefficient in JDK 1.1 days (e.g., JavaMail 1.0) are quite fast today. Maybe the smtp package will simply have to be removed in 2.0 for lack of demand, insufficient functionality, and by virtue of being obsolete. Regardless, anyone who uses the library (and even anyone who doesn't) who has criticisms of the API should not hesitate to offer their criticisms. You won't be hurting anyone's feelings. If the library is going to keep up with the times and be used for another seven years, it's got to be overhauled.
I really like the model for handling multipart content currently maintained in HttpClients MultipartPost method. For the most part, your going to either have content in memory or in a file on the filesystem, generically wrapping any "Part" including references to a file in the filesystem allows one not to have to put it into memory and still process it into the Writer/Stream without the user really needing to manage it.
http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/methods/MultipartPostMethod.html http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/methods/multipart/FilePart.html
If there is a consideration to work on the SMTP implementation. This is an excellent approach to consider.
Are Mutlipart Http Posts and Multipart SMPT messages encoded the same way or is the naming just a coincidence?
-Mark
-- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
