RE: [Request for Comment] Http Components proposal

[Noel J. Bergman]

> The plan is to factor the multipart content handling out
> of HttpClient. There's already a project in Commons
> Sandbox led by Mark R. Diggory [for] that end.  Unfortunately
> the project has been dormant for quite some time

See also: http://svn.apache.org/repos/asf/james/mime4j

--- Noel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Request for Comment] Http Components proposal

[robert burrell donkin]

On Sun, 2005-09-25 at 12:27 +0200, Oleg Kalnichevski wrote:
> On Sat, 2005-09-24 at 20:34 -0700, Martin Cooper wrote:
> > On 9/24/05, Henri Yandell <[EMAIL PROTECTED]> wrote:
> ...
> > > * Jakarta Http Components MUST be content agnostic. The project DOES NOT
> > > develop components intended to produce or consume content of HTTP
> > > messages.
> > 
> > 
> > While I understand what you're trying to say here, this wording appears to
> > preclude some of what is in HttpClient today, namely multipart content
> > handling.
> > 
> 
> Hi Martin,
> 
> This statement is not accidental. The plan is to factor the multipart
> content handling out of HttpClient. There's already a project in Commons
> Sandbox led by Mark R. Diggory
>  
> for that end. 
> Unfortunately the project has been dormant for quite some time but the plan 
> is to revive 
> the project at some point, get it graduate from Sandbox and possibly get it 
> merged with
> Commons Codec proper at some point of time.

IMHO a clause need to be inserted to allow the sub-project maintain the
existing codebase (since it will be out-of-scope otherwise). actually,
i'd prefer to see the pmc give the explicit responsibility for
maintenance to the sub-project.

> > > * Jakarta Http Components DOES NOT define a server side API on top of the
> > > low level transport API.
> > 
> > 
> > Again, I understand what you want to say. However, I think it would be
> > better said in terms that make it clear that it is intended for use on the
> > client side _of the protocol_, since many people are using HttpClient on the
> > server side today, but as a client to other servers.
> > 
> 
> Actually we see more and more often HttpClient code used to implement
> server side of the protocol as well. This statement is primarily to
> ensure that the project will not sidetrack into developing and
> _application_ API competing with javax.servlet API. We merely want to
> provide low level generic transport primitives. 

IMHO if this is the vision then it would be better to rephrase the final
clause to make this clear. maybe something like:

* Jakarta Http Components will provide ONLY a toolset of low level
generic transport APIs. In particular, server side application layer
APIs WILL NOT be developed.

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: ApacheCon (AC2k5US)

[Noel J. Bergman]

> I've started a wiki page to plan any Jakarta/Apache-Java BoFs etc at 
> ApacheCon this December

> http://wiki.apache.org/jakarta/AC2k5US

Shouldn't this be on http://wiki.apache.org/apachecon/ ?

--- Noel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANNOUNCE] HiveMind 1.1-rc-1

[Howard Lewis Ship]

This first release candidate for HiveMind 1.1 has been released. In a
sure sign of stability, it includes no functionality changes from
HiveMind 1.1-beta-3.

HiveMind may be downloaded from
http://jakarta.apache.org/site/downloads/downloads_hivemind.cgi
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta Wiki] Trivial Update of "AC2k5US" by HenningSchmiedehausen

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta Wiki" for 
change notification.

The following page has been changed by HenningSchmiedehausen:
http://wiki.apache.org/jakarta/AC2k5US

--
  
   * Henri Yandell
   * Torsten Curdt
+  * Henning Schmiedehausen
  
  == BoF Topics ==
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Request for Comment] Http Components proposal

[Oleg Kalnichevski]

On Sat, 2005-09-24 at 20:34 -0700, Martin Cooper wrote:
> On 9/24/05, Henri Yandell <[EMAIL PROTECTED]> wrote:
...
> > * Jakarta Http Components MUST be content agnostic. The project DOES NOT
> > develop components intended to produce or consume content of HTTP
> > messages.
> 
> 
> While I understand what you're trying to say here, this wording appears to
> preclude some of what is in HttpClient today, namely multipart content
> handling.
> 

Hi Martin,

This statement is not accidental. The plan is to factor the multipart
content handling out of HttpClient. There's already a project in Commons
Sandbox led by Mark R. Diggory
 for 
that end. Unfortunately the project has been dormant for quite some time but 
the plan is to revive the project at some point, get it graduate from Sandbox 
and possibly get it merged with Commons Codec proper at some point of time.

> > * Jakarta Http Components DOES NOT define a server side API on top of the
> > low level transport API.
> 
> 
> Again, I understand what you want to say. However, I think it would be
> better said in terms that make it clear that it is intended for use on the
> client side _of the protocol_, since many people are using HttpClient on the
> server side today, but as a client to other servers.
> 

Actually we see more and more often HttpClient code used to implement
server side of the protocol as well. This statement is primarily to
ensure that the project will not sidetrack into developing and
_application_ API competing with javax.servlet API. We merely want to
provide low level generic transport primitives. 

Oleg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]