hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpClient] multipart coded entities
Date Fri, 25 Jan 2008 20:40:21 GMT

On Fri, 2008-01-25 at 20:21 +0100, Roland Weber wrote:
> Hi Oleg,
> > I am going to approach James developers and ask them if they would be
> > interested in having our multipart encoder contributed to Mime4J. It may
> > well be they would not, given Mime4j's rather strong emphasis on the
> > decoding (parsing) side of things.
> I share your concerns. Apache is about communities, not code.
> Code without a community is dead, see Slide for an example. If
> the James folks were interested in our multipart code, we'd have
> seen them here by now, right? And if you wanted to maintain the
> code, why would you move it elsewhere in the first place? I'd
> expect this to end like the attempt to move multipart to
> commons-codec, or Norbert here to us. Code in some repository,
> but nobody doing anything with it. That won't help our users.
> And if there is a WebDAV client effort in the future, it will need
> multipart support and bring it back here (if WebDAV moves here).

Roland et al

I am sorry I was not quick enough to bring you up to date. I looked at
mine4j and found out it already had all the necessary primitives to
build MIME entities. The mine4j API looks quite reasonable. It can well
serve our needs and still be maintained outside HttpComponents by a
larger community. The implementation is somewhat buggy, at lest those
bits that we need. Filed a big report [1]. Still waiting for their
reaction. If James people respond positively to the patch I submitted,
we will get the functionality we need to retire our own MIME code.



[1] https://issues.apache.org/jira/browse/MIME4J-32

> > What should be our fallback option? Migrating old code to HttpClient 4
> > codeline? Dropping multipart support altogether? 
> It could become a part of HttpTidbits. That's a new component
> I intend to propose when the list of more important things to
> take care of has shortened significantly. Think of it as contrib
> code with pom.xml and web pages. No releases, Labs-style.
> cheers,
>   Roland
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org

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

View raw message