commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mart...@apache.org>
Subject Commons Multipart, anyone? (was: Re: [net] Why use Net for SMTP?)
Date Fri, 09 Jan 2004 18:51:15 GMT
On Fri, 9 Jan 2004, Mark R. Diggory wrote:

>
>
> 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?

They are both multipart MIME, but the specific MIME types are different.

I think a Commons Multipart component would be very interesting. We
already have multipart creation code in Commons HttpClient, and multipart
parsing code in Commons FileUpload. Breaking these out into something like
a Commons Multipart that could be used by both - and potentially by
Commons Net in more comprehensive mail handling - would be great.

I would be +1 on creating a Commons Multipart component, meaning that I am
willing to put in some time and effort, if other people are interested in
collaborating on such a beast.

Anyone else?

--
Martin Cooper


>
>
> -Mark
>
>

---------------------------------------------------------------------
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