Re: Commons Multipart, anyone?

Tim O'Brien wrote:

> On Fri, 9 Jan 2004, Mark R. Diggory wrote:
> 
> 
>>Martin Cooper wrote:
>>
>>>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, arn't we really 
>>possibly talking about a common multipart MIME Codec that would possibly 
>>be housed in the "codec" project?
> 
> 
> Mark, +1, and anyone who feels like committing this code to codec is 
> encouraged.  
> 
> Tim
> 

Most of the HttpClient encoding is in a static getParts method in 
o.a.c.h.methods.multipart.Part and in the individual "send" methods of 
the Part implmentation for HttpClient.

-Mark

p.s. I'm about +0.5 in terms of effort I can apply to this.

(Sorry for crossposting this, trying to keep it on the dev list, please 
respond there.)

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu