You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Martin Cooper <ma...@apache.org> on 2004/01/09 19:51:15 UTC
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 ...
> > Returning a writer was an efficient way of bypassing Java's terrible
> > (at the time) memory management and allowing large amounts of data
> > (i.e., many megabytes as in attachments) to be written to a stream without
> > buffering it all. The package was never intended to model email messages
> > or provide all the hooks of JAF, hence the C-like approach in this case of
> > "here's a stream, write your data to it." It's clear that people who look
> > at the library today want higher level functionality and that will have to
> > be accommodated in any future redesign. Also, with GHz processors,
> > GB memories, and fast JITs, better OO designs that were woefully inefficient
> > in JDK 1.1 days (e.g., JavaMail 1.0) are quite fast today. Maybe the smtp
> > package will simply have to be removed in 2.0 for lack of demand,
> > insufficient functionality, and by virtue of being obsolete. Regardless,
> > anyone who uses the library (and even anyone who doesn't) who has criticisms
> > of the API should not hesitate to offer their criticisms. You won't be
> > 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
>
>
> -Mark
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: Commons Multipart, anyone?
Posted by Eric Pugh <ep...@upstate.com>.
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:mdiggory@latte.harvard.edu]
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Multipart, anyone?
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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/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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Multipart, anyone?
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
I do agree. I also think its important to maintain some of the features
supported currently in HttpClient to benefit java.io.File processing
where large files may be encoded as they are "streamed" to the server. I
understand theres thought/effort going into Stream Encoders/Filters in
[codec]. This is probably an advantageous application of such a
practice. So there is another usage of codec which suggests it is a good
home for this.
-Mark
Oleg Kalnichevski wrote:
> 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
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Commons Multipart MIME?
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
I think a MIME Multipart project is a great idea (whether independent or
part of codec), and would be willing to contribute some time to it.
I have written (and continue to maintain) a b2b framework for my
employer. We use ebxml over IBM MQSeries to transfer messages around,
and ebxml uses MIME multipart ("soap with attachments") encoding to
bundle together message bodies with their relevant headers.
See: http://www.w3.org/TR/SOAP-attachments
and: http://webservices.xml.com/pub/a/ws/2003/03/18/ebxml.html
As stated elsewhere, Sun provides some multipart-mime stuff as part of
JavaMail, but this is really heavy and clumsy to work with (far too
mail-focused). All that JAF stuff, for example, just gets in the way.
Sun defines the "saaj" (Soap with Attachments API for Java), and
provides an implementation but this implementation depends on JAF and
JavaMail; again *way* too heavy for my purposes.
See: http://java.sun.com/xml/saaj/index.jsp
and: http://java.sun.com/webservices/docs/1.3/saaj/ReleaseNotes.html
I've got some horrible kludges coded up at the moment to do mime stuff,
but would be happy to help out with a proper generic mime multipart
library.
Cheers,
Simon
On Sat, 2004-01-10 at 17:45, Martin Cooper wrote:
> If we're going to put this MIME thingy together, it would seem that the
> issues being faced by James would provide a nice set of design criteria to
> add to the puzzle. A robust MIME library that would satisfy the needs of
> James, HttpClient, FileUpload, and possibly others, would be awesome.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [codec] multipart encoders/decoders
Posted by Brett Henderson <ja...@bretth.com>.
> Here are a few good rules of thumb:
>
> 1. Commons exists as an effort to encourage code reuse. The
> Streamable
> framework presented was interesting, but I'd like us to find
> an existing
> streamable Base64 implementation inside of the ASF codebase.
I have no problems with this but so far I haven't seen anything
like this that doesn't sub-class InputStream and OutputStream.
Sub-classing InputStream and OutputStream is problematic because
it forces you to code algorithms around IOStream semantics
(InputStream coding is not simple, especially available() method)
and it forces you to make the encoder sub-class OutputStream and
the decoder sub-class InputStream unless you write an
implementation for each stream type.
Providing a single InputStream implementation that can use an
underlying codec engine simplifies development and testing
of new algorithms considerably and removes the distinction between
input and output streams.
> 3. No need to expressly focus on a framework (at all). Codec
> is FIRSTLY a
> functional beast, even if the solution is inelegant. If there is an
> existing streamable Base64 in ASF, I'd recommend copying it
> outright and
> placing in the codec package. Over time, it can move towards
> a unified
> streamable framework.
I'm often guilty of over designing things, hey it's fun :-)
Would it help if I didn't call my classes a "framework"?
It's no more than a few common interfaces and some implementation
codecs. There are no factories, or service providers, or other
abstractions complicating things.
It really isn't much different to the existing codec interfaces
except that they are written to support streaming and separate
input and output interfaces.
I really think there's a need for all streamable codecs to follow
common interfaces. Perhaps InputStream and OutputStream are
sufficient but I think there's a better way.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [codec] multipart encoders/decoders
Posted by Tim O'Brien <to...@discursive.com>.
On Mon, 12 Jan 2004, Mark R. Diggory wrote:
> (3) work directly in the codec project?
Mark, please feel free to add this to the codec HEAD in commons proper.
Here are a few good rules of thumb:
1. Commons exists as an effort to encourage code reuse. The Streamable
framework presented was interesting, but I'd like us to find an existing
streamable Base64 implementation inside of the ASF codebase.
2. Once a product is in commons proper, forget the sandbox.
3. No need to expressly focus on a framework (at all). Codec is FIRSTLY a
functional beast, even if the solution is inelegant. If there is an
existing streamable Base64 in ASF, I'd recommend copying it outright and
placing in the codec package. Over time, it can move towards a unified
streamable framework.
>
> I currently have extracted the multipart post encoding from the
> HttpClient multipart post code and am working on an initial framework to
> support its addition to codec. I would like to get this into the sandbox
> soon but want to be flexible o others needs, if there is interest in
> also working on Streamable Codecs, my code would benefit from Streamable
> encoder/decoder interfaces, thus we should probably work on that code in
> the same place.
>
> -Mark
>
> Mark R. Diggory wrote:
>
> > Hmmm, thats a Hot Potato, I suspect we won't be using it (at least
> > initially). ;-)
> >
> > Maybe to focus in the initial deliverable we would require:
> >
> >> 2.) Multipart Mime Codecs
> >>
> >> Maintaining Multipart Encoding in the various multipart mimetypes.
> >
> >
> > Multipart Types (mostly email)
> > Messages with multiple parts multipart/mixed
> > Messages with multiple, alternative parts multipart/alternative
> > Message with multiple, related parts multipart/related
> > Multiple parts are digests multipart/digest
> > For reporting of email status (admin.) multipart/report
> > Order of parts does not matter multipart/parallel
> > Macintosh file data multipart/appledouble
> > Aggregate messages; descriptor as header multipart/header-set
> > Container for voice-mail multipart/voice-message
> > HTML FORM data (see Ch. 9 and App. B) multipart/form-data
> > Infinite multiparts - See Chapter 9 (Netscape) multipart/x-mixed-replace
> >
> >
> > 1.) Which do we want to support?
> >
> > 2.) How might we write an extensible (and nestable) API to encode/decode
> > various multiparts elegantly?
> >
> > Currently, HttpClient maintains this efficiently in the form of "Parts"
> >
> > MultipartPostMethod.addPart(Part part);
> >
> > Part
> > ---StringPart
> > ---FilePart
> >
> > All parts have a Part.send(OutputStream out) method responsible for
> > encoding and streaming the Parts contents to the MultipartPostMethod.
> >
> > 1.) This means that Parts are kept in their native Format/State/Object
> > until they are processed into the Steam.
> >
> > 2.) Currently in HttpClient, Parts also generate the "Multipart"
> > portions of the encoding (ie boundaries etc). Ideally, the "processor"
> > of the Part should probably be more responsible for this, with the Part
> > just generating a Stream of its content and the "codec" responsible for
> > the boundaries/encoding etc. This way, no matter the codec
> > (multipart/related, multipart/mixed, etc) the user is still working with
> > he same "Parts" and the only difference is the "codec"/"factory"). This
> > is similar in nature to the idea of service providers and JNDI. Your
> > still working with "Context/Attributes/SearchResults" no matter what
> > Service provider your using (DNS, LDAP, FS).
> >
> > 3.) This is why I initially though JAF would be a responsible choice,
> > delivering Parts that also had "mimetypes" associated with them, the
> > codec could then simply use the mimetype to determine the appropriate
> > encoding for that specific multipart codec.
> >
> > -Mark
> >
> > Serge Knystautas wrote:
> >
> >> Noel J. Bergman wrote:
> >>
> >>> Mark R. Diggory asked:
> >>>
> >>>> Shouldn't [mime] be dependent on JAF?
> >>>
> >>>
> >>>
> >>> Why?
> >>
> >>
> >>
> >> Looks like others already stated this, but here's my why/why not:
> >>
> >> why: it's an established API that doesn't have anything to do with
> >> MIME handling. JAF handles creating Java objects from streams. (This
> >> was listed as one of the tasks for this initiative, and I don't think
> >> it really belongs).
> >>
> >> why not: it's really really painful to use. It has a a decent idea of
> >> a data handler, but it's just way to complicated
> >>
> >> I would prefer JAF and otherwise object instantiation from streams be
> >> unrelated to mime. The reason it current works this way is so you can
> >> "nest" MimeMultipart objects, but I think there's a better way to wrap
> >> this.
> >>
> >
>
>
--
----------------------
Tim O'Brien
Evanston, IL
(847) 863-7045
tobrien@discursive.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[codec] multipart encoders/decoders
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
If we want eventually add multipart encoders/decoders to codec, should we:
(1) reopen the codec sandbox,
(2) start a new sandbox project, or
(3) work directly in the codec project?
I currently have extracted the multipart post encoding from the
HttpClient multipart post code and am working on an initial framework to
support its addition to codec. I would like to get this into the sandbox
soon but want to be flexible o others needs, if there is interest in
also working on Streamable Codecs, my code would benefit from Streamable
encoder/decoder interfaces, thus we should probably work on that code in
the same place.
-Mark
Mark R. Diggory wrote:
> Hmmm, thats a Hot Potato, I suspect we won't be using it (at least
> initially). ;-)
>
> Maybe to focus in the initial deliverable we would require:
>
>> 2.) Multipart Mime Codecs
>>
>> Maintaining Multipart Encoding in the various multipart mimetypes.
>
>
> Multipart Types (mostly email)
> Messages with multiple parts multipart/mixed
> Messages with multiple, alternative parts multipart/alternative
> Message with multiple, related parts multipart/related
> Multiple parts are digests multipart/digest
> For reporting of email status (admin.) multipart/report
> Order of parts does not matter multipart/parallel
> Macintosh file data multipart/appledouble
> Aggregate messages; descriptor as header multipart/header-set
> Container for voice-mail multipart/voice-message
> HTML FORM data (see Ch. 9 and App. B) multipart/form-data
> Infinite multiparts - See Chapter 9 (Netscape) multipart/x-mixed-replace
>
>
> 1.) Which do we want to support?
>
> 2.) How might we write an extensible (and nestable) API to encode/decode
> various multiparts elegantly?
>
> Currently, HttpClient maintains this efficiently in the form of "Parts"
>
> MultipartPostMethod.addPart(Part part);
>
> Part
> ---StringPart
> ---FilePart
>
> All parts have a Part.send(OutputStream out) method responsible for
> encoding and streaming the Parts contents to the MultipartPostMethod.
>
> 1.) This means that Parts are kept in their native Format/State/Object
> until they are processed into the Steam.
>
> 2.) Currently in HttpClient, Parts also generate the "Multipart"
> portions of the encoding (ie boundaries etc). Ideally, the "processor"
> of the Part should probably be more responsible for this, with the Part
> just generating a Stream of its content and the "codec" responsible for
> the boundaries/encoding etc. This way, no matter the codec
> (multipart/related, multipart/mixed, etc) the user is still working with
> he same "Parts" and the only difference is the "codec"/"factory"). This
> is similar in nature to the idea of service providers and JNDI. Your
> still working with "Context/Attributes/SearchResults" no matter what
> Service provider your using (DNS, LDAP, FS).
>
> 3.) This is why I initially though JAF would be a responsible choice,
> delivering Parts that also had "mimetypes" associated with them, the
> codec could then simply use the mimetype to determine the appropriate
> encoding for that specific multipart codec.
>
> -Mark
>
> Serge Knystautas wrote:
>
>> Noel J. Bergman wrote:
>>
>>> Mark R. Diggory asked:
>>>
>>>> Shouldn't [mime] be dependent on JAF?
>>>
>>>
>>>
>>> Why?
>>
>>
>>
>> Looks like others already stated this, but here's my why/why not:
>>
>> why: it's an established API that doesn't have anything to do with
>> MIME handling. JAF handles creating Java objects from streams. (This
>> was listed as one of the tasks for this initiative, and I don't think
>> it really belongs).
>>
>> why not: it's really really painful to use. It has a a decent idea of
>> a data handler, but it's just way to complicated
>>
>> I would prefer JAF and otherwise object instantiation from streams be
>> unrelated to mime. The reason it current works this way is so you can
>> "nest" MimeMultipart objects, but I think there's a better way to wrap
>> this.
>>
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Multipart MIME?
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Hmmm, thats a Hot Potato, I suspect we won't be using it (at least
initially). ;-)
Maybe to focus in the initial deliverable we would require:
> 2.) Multipart Mime Codecs
>
> Maintaining Multipart Encoding in the various multipart mimetypes.
Multipart Types (mostly email)
Messages with multiple parts multipart/mixed
Messages with multiple, alternative parts multipart/alternative
Message with multiple, related parts multipart/related
Multiple parts are digests multipart/digest
For reporting of email status (admin.) multipart/report
Order of parts does not matter multipart/parallel
Macintosh file data multipart/appledouble
Aggregate messages; descriptor as header multipart/header-set
Container for voice-mail multipart/voice-message
HTML FORM data (see Ch. 9 and App. B) multipart/form-data
Infinite multiparts - See Chapter 9 (Netscape) multipart/x-mixed-replace
1.) Which do we want to support?
2.) How might we write an extensible (and nestable) API to encode/decode
various multiparts elegantly?
Currently, HttpClient maintains this efficiently in the form of "Parts"
MultipartPostMethod.addPart(Part part);
Part
---StringPart
---FilePart
All parts have a Part.send(OutputStream out) method responsible for
encoding and streaming the Parts contents to the MultipartPostMethod.
1.) This means that Parts are kept in their native Format/State/Object
until they are processed into the Steam.
2.) Currently in HttpClient, Parts also generate the "Multipart"
portions of the encoding (ie boundaries etc). Ideally, the "processor"
of the Part should probably be more responsible for this, with the Part
just generating a Stream of its content and the "codec" responsible for
the boundaries/encoding etc. This way, no matter the codec
(multipart/related, multipart/mixed, etc) the user is still working with
he same "Parts" and the only difference is the "codec"/"factory"). This
is similar in nature to the idea of service providers and JNDI. Your
still working with "Context/Attributes/SearchResults" no matter what
Service provider your using (DNS, LDAP, FS).
3.) This is why I initially though JAF would be a responsible choice,
delivering Parts that also had "mimetypes" associated with them, the
codec could then simply use the mimetype to determine the appropriate
encoding for that specific multipart codec.
-Mark
Serge Knystautas wrote:
> Noel J. Bergman wrote:
>
>> Mark R. Diggory asked:
>>
>>> Shouldn't [mime] be dependent on JAF?
>>
>>
>> Why?
>
>
> Looks like others already stated this, but here's my why/why not:
>
> why: it's an established API that doesn't have anything to do with MIME
> handling. JAF handles creating Java objects from streams. (This was
> listed as one of the tasks for this initiative, and I don't think it
> really belongs).
>
> why not: it's really really painful to use. It has a a decent idea of a
> data handler, but it's just way to complicated
>
> I would prefer JAF and otherwise object instantiation from streams be
> unrelated to mime. The reason it current works this way is so you can
> "nest" MimeMultipart objects, but I think there's a better way to wrap
> this.
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Multipart MIME?
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> Mark R. Diggory asked:
>>Shouldn't [mime] be dependent on JAF?
>
> Why?
Looks like others already stated this, but here's my why/why not:
why: it's an established API that doesn't have anything to do with MIME
handling. JAF handles creating Java objects from streams. (This was
listed as one of the tasks for this initiative, and I don't think it
really belongs).
why not: it's really really painful to use. It has a a decent idea of a
data handler, but it's just way to complicated
I would prefer JAF and otherwise object instantiation from streams be
unrelated to mime. The reason it current works this way is so you can
"nest" MimeMultipart objects, but I think there's a better way to wrap this.
--
Serge Knystautas
President
Lokitech >>> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Multipart MIME?
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Mon, 2004-01-12 at 17:14, Mark R. Diggory wrote:
>
> Noel J. Bergman wrote:
>
> > Mark R. Diggory asked:
> >
> >
> >> Shouldn't [mime] be dependent on JAF?
> >
> >
> > Why?
> >
> > --- Noel
> >
>
> For a standardized cross platform means of resolving a streams mime-type
> to an appropriate Object (File, String, XML, etc). I know there are
> issues with how its used by JavaMail, but is this just poor
> implementation in JavaMail or a shortcoming in JAF specifically? From
> earlier references, JavaMail is observed to not be capable of handling
> large attachments (Multipart MIME SMTP) because of its "in memory"
> approach and because JavaMail throws exceptions when it can determine
> the mimetype of the data. Is this a fault in JavaMail or JAF. If its
> just JavaMail than JAF may/will still be of useful benefit.
>
> From Sun's site:
>
> > With the JavaBeans Activation Framework standard extension,
> > developers who use Java technology can take advantage of standard
> > services to determine the type of an arbitrary piece of data,
> > encapsulate access to it, discover the operations available on it,
> > and to instantiate the appropriate bean to perform said operation(s).
> > For example, if a browser obtained a JPEG image, this framework would
> > enable the browser to identify that stream of data as an JPEG image,
> > and from that type, the browser could locate and instantiate an
> > object that could manipulate, or view that image.
>
> -Mark
I tried to use JavaMail/JAF for the ebxml stuff I was doing, and gave
up. I think it is one of the nastiest Java APIs in existence, regardless
of whether the implementation is also broken.
It's really trying to do a very simple task; given a mime type and a
block of data, instantiate an object to handle the data. Quite how they
ended up with something so baroque I don't know.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Multipart MIME?
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Noel J. Bergman wrote:
> Mark R. Diggory asked:
>
>
>> Shouldn't [mime] be dependent on JAF?
>
>
> Why?
>
> --- Noel
>
For a standardized cross platform means of resolving a streams mime-type
to an appropriate Object (File, String, XML, etc). I know there are
issues with how its used by JavaMail, but is this just poor
implementation in JavaMail or a shortcoming in JAF specifically? From
earlier references, JavaMail is observed to not be capable of handling
large attachments (Multipart MIME SMTP) because of its "in memory"
approach and because JavaMail throws exceptions when it can determine
the mimetype of the data. Is this a fault in JavaMail or JAF. If its
just JavaMail than JAF may/will still be of useful benefit.
From Sun's site:
> With the JavaBeans Activation Framework standard extension,
> developers who use Java technology can take advantage of standard
> services to determine the type of an arbitrary piece of data,
> encapsulate access to it, discover the operations available on it,
> and to instantiate the appropriate bean to perform said operation(s).
> For example, if a browser obtained a JPEG image, this framework would
> enable the browser to identify that stream of data as an JPEG image,
> and from that type, the browser could locate and instantiate an
> object that could manipulate, or view that image.
-Mark
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Commons Multipart MIME?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Mark R. Diggory asked:
> Shouldn't [mime] be dependent on JAF?
Why?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Multipart MIME?
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Shouldn't [mime] be dependent on JAF?
Mark R. Diggory wrote:
> Hmm. Seems there are a few areas of focus here that it would be good to
> clarify.
>
> 1.) Mime-types
>
> Maintaining mappings for mimetypes.
>
> 2.) Multipart Mime Codecs
>
> Maintaining Multipart Encoding in the various multipart mimetypes.
>
> 3.) Architecture
>
> Providing datastructures for efficient processing of Multipart content
> with java.io (Files, Readers/Writers and Input/OutputStreams).
>
> Anything else?
>
> -Mark
>
> Martin Cooper wrote:
>
>> On Sat, 10 Jan 2004, Stephen Colebourne wrote:
>>
>>
>>> I don't have a direct need for a MIME type component myself, but this
>>> certainly sounds widely popular and useful.
>>>
>>> I would however suggest starting in the sandbox with a dependency on
>>> [codec]. That way you'll have more freedom of design to start with,
>>> and not
>>> block releases of [codec]. You may find that once complete you merge the
>>> mime code into codec, or you may find not. But leave that decision until
>>> later.
>>
>>
>>
>> +1. I was thinking along the same lines myself. Perhaps we start out in
>> the sandbox as [mime], and then when we have our act together, we can
>> have
>> a discussion about merging with [codec] or not. (I have a feeling that a
>> full MIME library would rather swamp the rest of Codec, at least as it is
>> today, but we can talk about that later, when we actually have code. ;)
>>
>> --
>> Martin Cooper
>>
>>
>>
>>> Stephen
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Multipart MIME?
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Hmm. Seems there are a few areas of focus here that it would be good to
clarify.
1.) Mime-types
Maintaining mappings for mimetypes.
2.) Multipart Mime Codecs
Maintaining Multipart Encoding in the various multipart mimetypes.
3.) Architecture
Providing datastructures for efficient processing of Multipart content
with java.io (Files, Readers/Writers and Input/OutputStreams).
Anything else?
-Mark
Martin Cooper wrote:
> On Sat, 10 Jan 2004, Stephen Colebourne wrote:
>
>
>>I don't have a direct need for a MIME type component myself, but this
>>certainly sounds widely popular and useful.
>>
>>I would however suggest starting in the sandbox with a dependency on
>>[codec]. That way you'll have more freedom of design to start with, and not
>>block releases of [codec]. You may find that once complete you merge the
>>mime code into codec, or you may find not. But leave that decision until
>>later.
>
>
> +1. I was thinking along the same lines myself. Perhaps we start out in
> the sandbox as [mime], and then when we have our act together, we can have
> a discussion about merging with [codec] or not. (I have a feeling that a
> full MIME library would rather swamp the rest of Codec, at least as it is
> today, but we can talk about that later, when we actually have code. ;)
>
> --
> Martin Cooper
>
>
>
>>Stephen
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Multipart MIME?
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 10 Jan 2004, Stephen Colebourne wrote:
> I don't have a direct need for a MIME type component myself, but this
> certainly sounds widely popular and useful.
>
> I would however suggest starting in the sandbox with a dependency on
> [codec]. That way you'll have more freedom of design to start with, and not
> block releases of [codec]. You may find that once complete you merge the
> mime code into codec, or you may find not. But leave that decision until
> later.
+1. I was thinking along the same lines myself. Perhaps we start out in
the sandbox as [mime], and then when we have our act together, we can have
a discussion about merging with [codec] or not. (I have a feeling that a
full MIME library would rather swamp the rest of Codec, at least as it is
today, but we can talk about that later, when we actually have code. ;)
--
Martin Cooper
>
> Stephen
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Multipart MIME?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I don't have a direct need for a MIME type component myself, but this
certainly sounds widely popular and useful.
I would however suggest starting in the sandbox with a dependency on
[codec]. That way you'll have more freedom of design to start with, and not
block releases of [codec]. You may find that once complete you merge the
mime code into codec, or you may find not. But leave that decision until
later.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Commons Multipart MIME?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Martin Cooper wrote:
> This started from a thread on commons-user entitled:
> [net] Why use Net for SMTP?
> where the question was asked: Given that JavaMail is standard and does the
> job, why would one choose to use the SMTP facilities in Commons Net?
JavaMail is largely oriented for clients, and has a design goal of being
easy to use for programmers, rather than being comprehensive. There are
major problems when we need to deal with large messages. JavaMail expects
JAF to know how to handle each Part, so when trying to process a message, if
there is a MIME type for which JAF doesn't have a mapping, it can throw an
exception simply by loading the message. The officially recommended
solution is to get the raw content stream, but then we're back to needing
our own code to process the contents if we want to do anything more than
transport the blob.
> If we're going to put this MIME thingy together, it would seem that the
> issues being faced by James would provide a nice set of design criteria to
> add to the puzzle. A robust MIME library that would satisfy the needs of
> James, HttpClient, FileUpload, and possibly others, would be awesome.
One capability, which I've mentioned before, that I would like to see
available is stream-oriented regex support. If we could process a set of
regular expressions during stream processing, it would be really helpful for
some applications.
--- Noel
We need this for James. It is pretty close to the top of the list in terms
of addressing issues related to user requests. Let's go for it.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Commons Multipart MIME?
Posted by Martin Cooper <ma...@apache.org>.
On Fri, 9 Jan 2004, Noel J. Bergman wrote:
> Can someone please explain the context for this discussion? I was not
Sorry, my fault. This started from a thread on commons-user entitled:
[net] Why use Net for SMTP?
where the question was asked: Given that JavaMail is standard and does the
job, why would one choose to use the SMTP facilities in Commons Net? This
led to a comment that, to make Commons Net useful in this respect, it may
need a higher level API. That, in turn, might involve multipart MIME
handling.
The topic of multipart handling in HttpClient then came up, which led me
back to thinking about the multipart handling in FileUpload, and how it
might be rather nice if we pulled all of this multipart handling out into
a common place, hence this fork of the original thread.
>From pulling multipart code out into a Commons Multipart component, we
have now come to talking about creating a shared MIME component, perhaps
within Commons Codec, which I think is a fine idea.
> entirely paying attention, and it seems to have come from elsewhere, but
> these items DEFINITELY caught my attention:
>
> > I think I could also offer my +0.5 in terms of contributing MIME
> > specific code.
>
> > 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.
>
> > 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.
>
> > If there is a consideration to work on the SMTP implementation. This is
> > an excellent approach to consider.
>
> One of the issues we have in James is the fact that JavaMail wants to do
> everything in memory, so we have limited abilities to parse and manipulate
> large messages. I have a project item on my plate to work on addressing
> that issue, so any discussion of code for parsing and processing MIME for
> SMTP messages has my immediate attention. I had started looking (NIH is a
> place in DC, not an attitude for a programmer) elsewhere for code (Java or
> C/C++), but had not yet found what I need.
Yah, I am, unfortunately, familiar with the limitations of JavaMail in
this respect. ;-)
If we're going to put this MIME thingy together, it would seem that the
issues being faced by James would provide a nice set of design criteria to
add to the puzzle. A robust MIME library that would satisfy the needs of
James, HttpClient, FileUpload, and possibly others, would be awesome.
--
Martin Cooper
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Commons Multipart MIME?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Can someone please explain the context for this discussion? I was not
entirely paying attention, and it seems to have come from elsewhere, but
these items DEFINITELY caught my attention:
> I think I could also offer my +0.5 in terms of contributing MIME
> specific code.
> 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.
> 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.
> If there is a consideration to work on the SMTP implementation. This is
> an excellent approach to consider.
One of the issues we have in James is the fact that JavaMail wants to do
everything in memory, so we have limited abilities to parse and manipulate
large messages. I have a project item on my plate to work on addressing
that issue, so any discussion of code for parsing and processing MIME for
SMTP messages has my immediate attention. I had started looking (NIH is a
place in DC, not an attitude for a programmer) elsewhere for code (Java or
C/C++), but had not yet found what I need.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Multipart, anyone?
Posted by Oleg Kalnichevski <ol...@bluewin.ch>.
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
Re: Commons Multipart, anyone?
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Commons Multipart, anyone?
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Multipart, anyone?
Posted by Tim O'Brien <to...@discursive.com>.
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
>
> -Mark
>
>
--
----------------------
Tim O'Brien
Evanston, IL
(847) 863-7045
tobrien@discursive.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Commons Multipart, anyone?
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org