Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Subject: Re: RFC: Fileupload 1.3 or 2.0?
From: Oleg Kalnichevski <olegk@apache.org>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <e75283b10707032242w62dea72cm300b1bbd9e6e9b13@mail.gmail.com>
References: <e75283b10707031227jd8929c9h56ea36c3cefa90ba@mail.gmail.com>
	 <16d6c6200707032011v556782f6j216aed70f0f522d2@mail.gmail.com>
	 <e75283b10707032242w62dea72cm300b1bbd9e6e9b13@mail.gmail.com>
Content-Type: text/plain
Date: Wed, 04 Jul 2007 12:10:24 +0200
Message-Id: <1183543824.4098.33.camel@okhost>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Wed, 2007-07-04 at 07:42 +0200, Jochen Wiedmann wrote:
> On 7/4/07, Martin Cooper <martinc@apache.org> wrote:
> 
> > * We were already starting to clone classes from what was originally
> > HttpClient and is now HttpComponents. One example is the ParameterParser
> > class. When I saw HttpComponents being born, saw a lot of other stuff in
> > there that FileUpload was doing, it looked like it would make a lot of sense
> > to build FileUpload on top of HttpComponents, thus dramatically cutting down
> > the amount of code necessary to build a FileUpload package.
> 
> I agree with you on that it might make sense to reuse components from
> outside, if possible. Unfortunately HttpComponents (in the person of
> Oleg Kalnichevski) has repeatedly declared that he has no interest in
> adding a multipart parser to httpcomponents, which would be (IMO) the
> most important part. Instead he suggested to add such a parser to
> Commons Codec. I personally believe, that this extends the scope of
> Commons Codec. But yes, if possible, I'd still be interested to reuse
> another multipart parser. Do you know of any ASL licensed?
> 

Jochen

You may want to take a look at Apache JAMES Mime4j [1]

As to why we currently have no plans to provide support MIME coding in
HttpComponents, there is more to it then just my trying to be difficult.
We are simply precluded from developing content codecs by the project
charter. It is one of several restrictions that were imposed on the
project in order to secure an approval of the Jakarta PMC. However,
given the fact that HttpComponents will most definitely have to leave
Jakarta for another TLP or form a TLP of its own, the project charter
may be revisited and revised. Having said that, I am still convinced
HttpComponents ought not expand its scope beyond low level HTTP
transport aspects and would prefer to work with other projects such as
JAMES or Commons toward development of a set of transport independent
content codecs.

Oleg 

[1] http://james.apache.org/mime4j/index.html
[2]
http://svn.apache.org/repos/asf/jakarta/httpcomponents/project/project-charter.txt 

> 
> Thanks,
> 
> Jochen
> 


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