commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [net] Why use Net for SMTP?
Date Fri, 09 Jan 2004 14:58:19 GMT


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: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message