Martin Cooper wrote:
Sorry, I should have sent this to -dev...
---------- Forwarded message ---------- Date: Fri, 9 Jan 2004 10:51:15 -0800 (PST) From: Martin Cooper <[EMAIL PROTECTED]> To: Jakarta Commons Users List <[EMAIL PROTECTED]> Subject: Commons Multipart, anyone? (was: Re: [net] Why use Net for SMTP?)
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 ...
...
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
If we're talking about Encoding/Decoding mutlipart MIME, aren't we really possibly talking about a common multipart MIME Codec that would possibly be housed in the "codec" project?
-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]
