You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2008/01/21 16:58:20 UTC
[HttpClient] multipart coded entities
Folks
Sorting out the support for multipart coded requests is the next item on
my to-do list.
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.
What should be our fallback option? Migrating old code to HttpClient 4
codeline? Dropping multipart support altogether?
Thoughts?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [HttpClient] multipart coded entities
Posted by Julius Davies <ju...@gmail.com>.
I agree with Odi. Using the javax.mail stuff is pretty awkward.
The built-in MIME support inside HttpClient has been really convenient
for a lot of people.
ps. to see what I mean by "javax.mail" being awkward, here's an
example of parsing MIME, rather than creating MIME:
http://markmail.org/message/wezfzjztshn75bwh
pps. sometimes I wonder, though, why people don't do that instead of
commons-upload....!
yours,
Julius
On Jan 21, 2008 8:09 AM, Ortwin Glück <od...@odi.ch> wrote:
>
>
> Oleg Kalnichevski wrote:
> > What should be our fallback option? Migrating old code to HttpClient 4
> > codeline? Dropping multipart support altogether?
> >
> > Thoughts?
>
> Having multipart MIME support *is* important. It's basically
> indispensible if you are serious about HTTP. So I am for a migration.
>
> Odi
>
> --
> [web] http://www.odi.ch/
> [blog] http://www.odi.ch/weblog/
> [pgp] key 0x81CF3416
> finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
--
yours,
Julius Davies
250-592-2284 (Home)
250-893-4579 (Mobile)
http://juliusdavies.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [HttpClient] multipart coded entities
Posted by Ortwin Glück <od...@odi.ch>.
Oleg Kalnichevski wrote:
> What should be our fallback option? Migrating old code to HttpClient 4
> codeline? Dropping multipart support altogether?
>
> Thoughts?
Having multipart MIME support *is* important. It's basically
indispensible if you are serious about HTTP. So I am for a migration.
Odi
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [HttpClient] multipart coded entities
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2008-01-25 at 21:40 +0100, Oleg Kalnichevski wrote:
> 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.
>
Oh man! My spelling sucks
mine4j = mime4j
Filed a big report = Filed a bug report
Oleg
> Cheers
>
> Oleg
>
> [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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [HttpClient] multipart coded entities
Posted by Roland Weber <os...@dubioso.net>.
Hi Oleg,
> 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.
That is good news indeed. I wouldn't mind having a whole collection
of entities based on mime4j, javax.mail, Commons FileUpload and
whatever else to choose from in our contrib code. If mime4j works
for our purposes, it can become the one implementation we support
for HttpClient. Even better if it works for receiving as well.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [HttpClient] multipart coded entities
Posted by Oleg Kalnichevski <ol...@apache.org>.
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.
Cheers
Oleg
[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
Re: [HttpClient] multipart coded entities
Posted by Roland Weber <os...@dubioso.net>.
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).
> 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