commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@bluewin.ch>
Subject Re: Commons Multipart, anyone?
Date Fri, 09 Jan 2004 21:00:18 GMT
I am happy to provide whatever assistance necessary on the HttpClient
side. I think I could also offer my +0.5 in terms of contributing MIME
specific code.

Taking this opportunity, allow me to suggest MIME related classes be
folded into Commons-Codec instead of being spawned as a separate
project. MIME classes would inevitably require several codecs (Base64
and quote-printable encoding at the very least) to be of any use in
applications targeting international audience, primarily due to the fact
that per definition non-ASCII characters in MIME headers must be
escaped. That makes me believe that a lot of projects that require
Commons-MIME would also benefit from Commons-Codec and visa versa. I
understand that there will be users who would prefer finer granularity
in Commons projects, but in this particular case they should not
represent the majority.

Oleg


On Fri, 2004-01-09 at 20:34, Mark R. Diggory wrote:
> 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.)


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message