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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
