Here is another project that could take advantage of MIME data: Fulcrum MIME component: http://jakarta.apache.org/turbine/fulcrum/fulcrum-mimetype/index.html
Eric > -----Original Message----- > From: Mark R. Diggory [mailto:[EMAIL PROTECTED] > Sent: Friday, January 09, 2004 9:08 PM > To: Jakarta Commons Developers List > Subject: Re: Commons Multipart, anyone? > > > Here are a list of projects I think would benefit from a common codec > for multipart mime encodings (capable of various mime types) or some > sort of consolidation of Multipart Encoding into a Common codebase. > > Web Services: SOAP > Web Services: XML-RPC > Jakarta Commons: HttpClient > Jakarta Commons: Net > Jakarta Commons: FileUpload > Jakarta: Struts > > If you can think of any other please include them. I thought > this might > also be of benefit to the Web Services folks because I know > tools like > Soap and XML-RPC send messages over both HTTP and SMTP and > that there > is work that needs to be done in these projects concerning > multipart SMTP. > > -Mark > > 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: > >>>>> 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/c > ommons/httpclient/methods/MultipartPostMethod.html > >>>>> > >>>>> > http://jakarta.apache.org/commons/httpclient/xref/org/apache/c > ommons/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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
