You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Trustin Lee <tr...@gmail.com> on 2007/11/19 05:25:06 UTC

mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

Hi,

I'd like to discuss 2 ideas in this post.  (Apologies for cross-posting ;)

1) What do you think about merging existing mina-protocol-http-client
module into asyncweb?  Then AsyncWeb could be a one stop solution for
HTTP client-server communication.  Now the codec is separated from
them into mina-filter-codec-http module, so the number of classes are
pretty small.

2) I also think mina-protocol-http-client module needs more work to
provide enough features to compare with existing HTTP client libraries
such as Jakarta HttpComponents, so moving it into sandbox might be a
better solution considering that we are going to release MINA 2.0.0-M1
soon and we don't want to release unfinished module.  It also might be
the best idea to cooperate with HttpComponents team to make our
current HTTP codec (i.e. mina-filter-codec-http) and mina-core plug
into HttpComponents NIO extension very easily.  I'd like to know what
the HttpComponents team think about this issue.

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

Posted by Paul Fremantle <pz...@gmail.com>.
>
> > If the intent is to entirely replace HTTPNIO, then there are at least 4
> > frameworks that could fit the bill:
>

Not at all! We love HTTPCore NIO! We are using it in Synapse and its very
effective.

Paul

RE: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2007-11-23 at 10:47 -0500, Rezaei, Mohammad A. wrote:
> If the intent is to entirely replace HTTPNIO, then there are at least 4
> frameworks that could fit the bill:
> 
> http://nioframework.sourceforge.net/
> https://grizzly.dev.java.net/
> http://sourceforge.net/projects/xsocket/
> http://mina.apache.org/
> 
> A very recent and interesting thread:
> 
> http://forum.java.sun.com/thread.jspa?threadID=5213915&tstart=0
> 
> There are older benchmarks out there that compare Grizzly and Mina. 
> 
> NIO is all about performance and scalability, so it should be straight
> forward to choose a framework.
> 
> Thanks
> Moh
> 

Hi Mohammad,

No, there is no such intent. I personally think it still makes sense to
continue offering HttpCore as a zero dependency HTTP engine capable of
both synchronous and asynchronous I/O based on our own NIO framework.
NIO extensions were built to be minimalistic, fast, memory efficient,
and tailored specifically to requirements of the HTTP protocol. Having
said that, we should also support a more generic NIO framework for those
cases when people want to run multiple protocols on top of the same I/O
infrastructure. I am also of opinion MINA 1.x is fatally flawed, so it
would not be my personal choice. Hopefully MINA 2.0 will have a better
memory management.

Cheers,

Oleg


> >-----Original Message-----
> >From: Oleg Kalnichevski [mailto:olegk@apache.org] 
> >Sent: Friday, November 23, 2007 5:13 AM
> >To: HttpComponents Project
> >Subject: Re: mina-protocol-http-client, AsyncWeb and Jakarta 
> >HttpComponents
> >
> >
> >On Fri, 2007-11-23 at 09:46 +0000, Paul Fremantle wrote:
> >> As a user of HTTPNIO I'd like to see HTTPNIO-on-MINA because 
> >I can naturally
> >> see some people wanting to have all NIO comms going via 
> >MINA, and some other
> >> transports we are looking at in Synapse are based on MINA. 
> >But given that
> >> Apache is a "do-ocracy" and my Non-Blocking coding skills 
> >are minimal I
> >> think I will shut up now!
> >> 
> >> Paul
> >> 
> >
> >Hi Paul
> >
> >HttpCore is designed to be portable to other I/O frameworks. For
> >instance, LimeWire folks put HttpCore protocol layer on top of 
> >their own
> >NIO code and it seems to be working quite well. I personally would like
> >to see HttpCore ported to Apache APR and Grizzly at some point of time.
> >HttpCore port to MINA, however, may pose problems both technical and as
> >well as personal. I approached MINA people a while ago and 
> >asked them to
> >not start a competing project within ASF but rather cooperate with us,
> >or at the very least try to minimize potential overlap between 
> >projects.
> >They refused. Some did that in a very offensive manner. 
> >
> >I am aware I have a tendency of being difficult on the personal level,
> >so I want to stay away from everything MINA related, but will happily
> >assist anyone interested in using HttpComponents on top of MINA.
> >
> >Evil Comrade Oleg
> >
> >
> >> On Nov 23, 2007 5:52 AM, Trustin Lee <tr...@gmail.com> wrote:
> >> 
> >> > Hello Roland,
> >> >
> >> > Thanks for the response.  Let's wait and see how people think about
> >> > this issue.  Probably Jeff will also have something to say.  :)
> >> >
> >> > Cheers,
> >> > Trustin
> >> >
> >> > On Nov 23, 2007 3:06 AM, Roland Weber <os...@dubioso.net> wrote:
> >> > > Hello Trustin,
> >> > >
> >> > > re-inventing the wheel is never a good thing. To me, it sounds
> >> > > reasonable that HttpComponents and MINA cooperate on the client
> >> > > side, at least for the higher level functionality. There is of
> >> > > course some kind of competition on the lower levels, where
> >> > > HttpNIO and MINA address similar functionality. IIRC, Oleg had
> >> > > slightly different design goals for HttpNIO. At the same time,
> >> > > he made sure that MINA can be used to implement the HttpNIO API.
> >> > > So yes, I can see potential for joined efforts: higher-level
> >> > > client functionality like HttpAuth and HttpCookie, and also
> >> > > a low-level component HttpNIO-on-MINA.
> >> > >
> >> > > But since Java NIO is not within my sphere of interest,
> >> > > I have to leave it to others to figure this out (or not).
> >> > >
> >> > > cheers,
> >> > >   Roland
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > what we call human nature is actually human habit
> >> > --
> >> > http://gleamynode.net/
> >> > --
> >> > PGP Key ID: 0x0255ECA6
> >> >
> >> > 
> >---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: 
> >httpcomponents-dev-unsubscribe@jakarta.apache.org
> >> > For additional commands, e-mail:
> >> > httpcomponents-dev-help@jakarta.apache.org
> >> >
> >> >
> >> 
> >> 
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: 
> >httpcomponents-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: 
> >httpcomponents-dev-help@jakarta.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> 
> 


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

RE: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

Posted by Tatu Saloranta <co...@yahoo.com>.
--- "Rezaei, Mohammad A." <Mo...@gs.com> 

> NIO is all about performance and scalability, so it
> should be straight
> forward to choose a framework.

More specifically, NIO is mostly about scalability,
and not all that much about performance. At least if
performance is thought of as efficiency.
NIO can be used to alleviate specific concurrency
problems (one thread per connection, lotsa inactive
open connections), and allows scaling things to
systems with higher concurrency demands. But generally
it does not help with throughput, for example.

-+ Tatu +-



      ____________________________________________________________________________________
Be a better sports nut!  Let your teams follow you 
with Yahoo Mobile. Try it now.  http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

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

RE: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

Posted by "Rezaei, Mohammad A." <Mo...@gs.com>.
If the intent is to entirely replace HTTPNIO, then there are at least 4
frameworks that could fit the bill:

http://nioframework.sourceforge.net/
https://grizzly.dev.java.net/
http://sourceforge.net/projects/xsocket/
http://mina.apache.org/

A very recent and interesting thread:

http://forum.java.sun.com/thread.jspa?threadID=5213915&tstart=0

There are older benchmarks out there that compare Grizzly and Mina. 

NIO is all about performance and scalability, so it should be straight
forward to choose a framework.

Thanks
Moh

>-----Original Message-----
>From: Oleg Kalnichevski [mailto:olegk@apache.org] 
>Sent: Friday, November 23, 2007 5:13 AM
>To: HttpComponents Project
>Subject: Re: mina-protocol-http-client, AsyncWeb and Jakarta 
>HttpComponents
>
>
>On Fri, 2007-11-23 at 09:46 +0000, Paul Fremantle wrote:
>> As a user of HTTPNIO I'd like to see HTTPNIO-on-MINA because 
>I can naturally
>> see some people wanting to have all NIO comms going via 
>MINA, and some other
>> transports we are looking at in Synapse are based on MINA. 
>But given that
>> Apache is a "do-ocracy" and my Non-Blocking coding skills 
>are minimal I
>> think I will shut up now!
>> 
>> Paul
>> 
>
>Hi Paul
>
>HttpCore is designed to be portable to other I/O frameworks. For
>instance, LimeWire folks put HttpCore protocol layer on top of 
>their own
>NIO code and it seems to be working quite well. I personally would like
>to see HttpCore ported to Apache APR and Grizzly at some point of time.
>HttpCore port to MINA, however, may pose problems both technical and as
>well as personal. I approached MINA people a while ago and 
>asked them to
>not start a competing project within ASF but rather cooperate with us,
>or at the very least try to minimize potential overlap between 
>projects.
>They refused. Some did that in a very offensive manner. 
>
>I am aware I have a tendency of being difficult on the personal level,
>so I want to stay away from everything MINA related, but will happily
>assist anyone interested in using HttpComponents on top of MINA.
>
>Evil Comrade Oleg
>
>
>> On Nov 23, 2007 5:52 AM, Trustin Lee <tr...@gmail.com> wrote:
>> 
>> > Hello Roland,
>> >
>> > Thanks for the response.  Let's wait and see how people think about
>> > this issue.  Probably Jeff will also have something to say.  :)
>> >
>> > Cheers,
>> > Trustin
>> >
>> > On Nov 23, 2007 3:06 AM, Roland Weber <os...@dubioso.net> wrote:
>> > > Hello Trustin,
>> > >
>> > > re-inventing the wheel is never a good thing. To me, it sounds
>> > > reasonable that HttpComponents and MINA cooperate on the client
>> > > side, at least for the higher level functionality. There is of
>> > > course some kind of competition on the lower levels, where
>> > > HttpNIO and MINA address similar functionality. IIRC, Oleg had
>> > > slightly different design goals for HttpNIO. At the same time,
>> > > he made sure that MINA can be used to implement the HttpNIO API.
>> > > So yes, I can see potential for joined efforts: higher-level
>> > > client functionality like HttpAuth and HttpCookie, and also
>> > > a low-level component HttpNIO-on-MINA.
>> > >
>> > > But since Java NIO is not within my sphere of interest,
>> > > I have to leave it to others to figure this out (or not).
>> > >
>> > > cheers,
>> > >   Roland
>> > >
>> >
>> >
>> >
>> > --
>> > what we call human nature is actually human habit
>> > --
>> > http://gleamynode.net/
>> > --
>> > PGP Key ID: 0x0255ECA6
>> >
>> > 
>---------------------------------------------------------------------
>> > To unsubscribe, e-mail: 
>httpcomponents-dev-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail:
>> > httpcomponents-dev-help@jakarta.apache.org
>> >
>> >
>> 
>> 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: 
>httpcomponents-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: 
>httpcomponents-dev-help@jakarta.apache.org
>

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

Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2007-11-23 at 11:31 +0000, Paul Fremantle wrote:
> Oleg
> 
> They refused. Some did that in a very offensive manner.
> 
> 
> I understood there might be some feeling about this which is why I said:
> 
> > > think I will shut up now!
> >
> 
> However, I think you're attitude is right - if there are people here who are
> willing to try to work with MINA then we should, but if no-one has time or
> inclination, I don't think we should worry about it either.
> 
> I like the idea of putting HTTPCore over APR.  What is Grizzly?
> 

Grizzly is a NIO framework / a set of HTTP components used by Sun's
Glassfish application server. 

I still have to take a closer look at it, but from what I have learned
so far, Grizzly appears to be more compatible with HttpCore's way of
doing NIO and it does not seem to have the shortcomings MINA has. 

https://grizzly.dev.java.net/

Oleg


> Paul
> 
> 
> 
> 
> 
> >
> > I am aware I have a tendency of being difficult on the personal level,
> > so I want to stay away from everything MINA related, but will happily
> > assist anyone interested in using HttpComponents on top of MINA.
> >
> > Evil Comrade Oleg
> >
> >
> > > On Nov 23, 2007 5:52 AM, Trustin Lee <tr...@gmail.com> wrote:
> > >
> > > > Hello Roland,
> > > >
> > > > Thanks for the response.  Let's wait and see how people think about
> > > > this issue.  Probably Jeff will also have something to say.  :)
> > > >
> > > > Cheers,
> > > > Trustin
> > > >
> > > > On Nov 23, 2007 3:06 AM, Roland Weber <os...@dubioso.net> wrote:
> > > > > Hello Trustin,
> > > > >
> > > > > re-inventing the wheel is never a good thing. To me, it sounds
> > > > > reasonable that HttpComponents and MINA cooperate on the client
> > > > > side, at least for the higher level functionality. There is of
> > > > > course some kind of competition on the lower levels, where
> > > > > HttpNIO and MINA address similar functionality. IIRC, Oleg had
> > > > > slightly different design goals for HttpNIO. At the same time,
> > > > > he made sure that MINA can be used to implement the HttpNIO API.
> > > > > So yes, I can see potential for joined efforts: higher-level
> > > > > client functionality like HttpAuth and HttpCookie, and also
> > > > > a low-level component HttpNIO-on-MINA.
> > > > >
> > > > > But since Java NIO is not within my sphere of interest,
> > > > > I have to leave it to others to figure this out (or not).
> > > > >
> > > > > cheers,
> > > > >   Roland
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > what we call human nature is actually human habit
> > > > --
> > > > http://gleamynode.net/
> > > > --
> > > > PGP Key ID: 0x0255ECA6
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > httpcomponents-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > > httpcomponents-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > httpcomponents-dev-help@jakarta.apache.org
> >
> >
> 
> 


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

Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

Posted by Paul Fremantle <pz...@gmail.com>.
Oleg

They refused. Some did that in a very offensive manner.


I understood there might be some feeling about this which is why I said:

> > think I will shut up now!
>

However, I think you're attitude is right - if there are people here who are
willing to try to work with MINA then we should, but if no-one has time or
inclination, I don't think we should worry about it either.

I like the idea of putting HTTPCore over APR.  What is Grizzly?

Paul





>
> I am aware I have a tendency of being difficult on the personal level,
> so I want to stay away from everything MINA related, but will happily
> assist anyone interested in using HttpComponents on top of MINA.
>
> Evil Comrade Oleg
>
>
> > On Nov 23, 2007 5:52 AM, Trustin Lee <tr...@gmail.com> wrote:
> >
> > > Hello Roland,
> > >
> > > Thanks for the response.  Let's wait and see how people think about
> > > this issue.  Probably Jeff will also have something to say.  :)
> > >
> > > Cheers,
> > > Trustin
> > >
> > > On Nov 23, 2007 3:06 AM, Roland Weber <os...@dubioso.net> wrote:
> > > > Hello Trustin,
> > > >
> > > > re-inventing the wheel is never a good thing. To me, it sounds
> > > > reasonable that HttpComponents and MINA cooperate on the client
> > > > side, at least for the higher level functionality. There is of
> > > > course some kind of competition on the lower levels, where
> > > > HttpNIO and MINA address similar functionality. IIRC, Oleg had
> > > > slightly different design goals for HttpNIO. At the same time,
> > > > he made sure that MINA can be used to implement the HttpNIO API.
> > > > So yes, I can see potential for joined efforts: higher-level
> > > > client functionality like HttpAuth and HttpCookie, and also
> > > > a low-level component HttpNIO-on-MINA.
> > > >
> > > > But since Java NIO is not within my sphere of interest,
> > > > I have to leave it to others to figure this out (or not).
> > > >
> > > > cheers,
> > > >   Roland
> > > >
> > >
> > >
> > >
> > > --
> > > what we call human nature is actually human habit
> > > --
> > > http://gleamynode.net/
> > > --
> > > PGP Key ID: 0x0255ECA6
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> httpcomponents-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > httpcomponents-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpcomponents-dev-help@jakarta.apache.org
>
>


-- 
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair

blog: http://pzf.fremantle.org
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2007-11-23 at 09:46 +0000, Paul Fremantle wrote:
> As a user of HTTPNIO I'd like to see HTTPNIO-on-MINA because I can naturally
> see some people wanting to have all NIO comms going via MINA, and some other
> transports we are looking at in Synapse are based on MINA. But given that
> Apache is a "do-ocracy" and my Non-Blocking coding skills are minimal I
> think I will shut up now!
> 
> Paul
> 

Hi Paul

HttpCore is designed to be portable to other I/O frameworks. For
instance, LimeWire folks put HttpCore protocol layer on top of their own
NIO code and it seems to be working quite well. I personally would like
to see HttpCore ported to Apache APR and Grizzly at some point of time.
HttpCore port to MINA, however, may pose problems both technical and as
well as personal. I approached MINA people a while ago and asked them to
not start a competing project within ASF but rather cooperate with us,
or at the very least try to minimize potential overlap between projects.
They refused. Some did that in a very offensive manner. 

I am aware I have a tendency of being difficult on the personal level,
so I want to stay away from everything MINA related, but will happily
assist anyone interested in using HttpComponents on top of MINA.

Evil Comrade Oleg


> On Nov 23, 2007 5:52 AM, Trustin Lee <tr...@gmail.com> wrote:
> 
> > Hello Roland,
> >
> > Thanks for the response.  Let's wait and see how people think about
> > this issue.  Probably Jeff will also have something to say.  :)
> >
> > Cheers,
> > Trustin
> >
> > On Nov 23, 2007 3:06 AM, Roland Weber <os...@dubioso.net> wrote:
> > > Hello Trustin,
> > >
> > > re-inventing the wheel is never a good thing. To me, it sounds
> > > reasonable that HttpComponents and MINA cooperate on the client
> > > side, at least for the higher level functionality. There is of
> > > course some kind of competition on the lower levels, where
> > > HttpNIO and MINA address similar functionality. IIRC, Oleg had
> > > slightly different design goals for HttpNIO. At the same time,
> > > he made sure that MINA can be used to implement the HttpNIO API.
> > > So yes, I can see potential for joined efforts: higher-level
> > > client functionality like HttpAuth and HttpCookie, and also
> > > a low-level component HttpNIO-on-MINA.
> > >
> > > But since Java NIO is not within my sphere of interest,
> > > I have to leave it to others to figure this out (or not).
> > >
> > > cheers,
> > >   Roland
> > >
> >
> >
> >
> > --
> > what we call human nature is actually human habit
> > --
> > http://gleamynode.net/
> > --
> > PGP Key ID: 0x0255ECA6
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > httpcomponents-dev-help@jakarta.apache.org
> >
> >
> 
> 


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

Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

Posted by Paul Fremantle <pz...@gmail.com>.
As a user of HTTPNIO I'd like to see HTTPNIO-on-MINA because I can naturally
see some people wanting to have all NIO comms going via MINA, and some other
transports we are looking at in Synapse are based on MINA. But given that
Apache is a "do-ocracy" and my Non-Blocking coding skills are minimal I
think I will shut up now!

Paul

On Nov 23, 2007 5:52 AM, Trustin Lee <tr...@gmail.com> wrote:

> Hello Roland,
>
> Thanks for the response.  Let's wait and see how people think about
> this issue.  Probably Jeff will also have something to say.  :)
>
> Cheers,
> Trustin
>
> On Nov 23, 2007 3:06 AM, Roland Weber <os...@dubioso.net> wrote:
> > Hello Trustin,
> >
> > re-inventing the wheel is never a good thing. To me, it sounds
> > reasonable that HttpComponents and MINA cooperate on the client
> > side, at least for the higher level functionality. There is of
> > course some kind of competition on the lower levels, where
> > HttpNIO and MINA address similar functionality. IIRC, Oleg had
> > slightly different design goals for HttpNIO. At the same time,
> > he made sure that MINA can be used to implement the HttpNIO API.
> > So yes, I can see potential for joined efforts: higher-level
> > client functionality like HttpAuth and HttpCookie, and also
> > a low-level component HttpNIO-on-MINA.
> >
> > But since Java NIO is not within my sphere of interest,
> > I have to leave it to others to figure this out (or not).
> >
> > cheers,
> >   Roland
> >
>
>
>
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpcomponents-dev-help@jakarta.apache.org
>
>


-- 
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair

blog: http://pzf.fremantle.org
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

Posted by Trustin Lee <tr...@gmail.com>.
Hello Roland,

Thanks for the response.  Let's wait and see how people think about
this issue.  Probably Jeff will also have something to say.  :)

Cheers,
Trustin

On Nov 23, 2007 3:06 AM, Roland Weber <os...@dubioso.net> wrote:
> Hello Trustin,
>
> re-inventing the wheel is never a good thing. To me, it sounds
> reasonable that HttpComponents and MINA cooperate on the client
> side, at least for the higher level functionality. There is of
> course some kind of competition on the lower levels, where
> HttpNIO and MINA address similar functionality. IIRC, Oleg had
> slightly different design goals for HttpNIO. At the same time,
> he made sure that MINA can be used to implement the HttpNIO API.
> So yes, I can see potential for joined efforts: higher-level
> client functionality like HttpAuth and HttpCookie, and also
> a low-level component HttpNIO-on-MINA.
>
> But since Java NIO is not within my sphere of interest,
> I have to leave it to others to figure this out (or not).
>
> cheers,
>   Roland
>



-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

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

Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

Posted by Trustin Lee <tr...@gmail.com>.
Hello Roland,

Thanks for the response.  Let's wait and see how people think about
this issue.  Probably Jeff will also have something to say.  :)

Cheers,
Trustin

On Nov 23, 2007 3:06 AM, Roland Weber <os...@dubioso.net> wrote:
> Hello Trustin,
>
> re-inventing the wheel is never a good thing. To me, it sounds
> reasonable that HttpComponents and MINA cooperate on the client
> side, at least for the higher level functionality. There is of
> course some kind of competition on the lower levels, where
> HttpNIO and MINA address similar functionality. IIRC, Oleg had
> slightly different design goals for HttpNIO. At the same time,
> he made sure that MINA can be used to implement the HttpNIO API.
> So yes, I can see potential for joined efforts: higher-level
> client functionality like HttpAuth and HttpCookie, and also
> a low-level component HttpNIO-on-MINA.
>
> But since Java NIO is not within my sphere of interest,
> I have to leave it to others to figure this out (or not).
>
> cheers,
>   Roland
>



-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

Posted by Roland Weber <os...@dubioso.net>.
Hello Trustin,

re-inventing the wheel is never a good thing. To me, it sounds
reasonable that HttpComponents and MINA cooperate on the client
side, at least for the higher level functionality. There is of
course some kind of competition on the lower levels, where
HttpNIO and MINA address similar functionality. IIRC, Oleg had
slightly different design goals for HttpNIO. At the same time,
he made sure that MINA can be used to implement the HttpNIO API.
So yes, I can see potential for joined efforts: higher-level
client functionality like HttpAuth and HttpCookie, and also
a low-level component HttpNIO-on-MINA.

But since Java NIO is not within my sphere of interest,
I have to leave it to others to figure this out (or not).

cheers,
  Roland

Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

Posted by Trustin Lee <tr...@gmail.com>.
That sounds exciting!  I also hope it compiles OK against the latest
mina-filter-codec-http module.  Let me look forward incoming patches
from you.  When would you post the patch? :)

Trustin

On Nov 19, 2007 11:59 PM, Jeff Genender <jg...@apache.org> wrote:
> Whoops and forgot to mention...this version also has response timeouts
> working as well.
>
> Jeff
>
>
> Jeff Genender wrote:
> >
> > Trustin Lee wrote:
> >> 2) I also think mina-protocol-http-client module needs more work to
> >> provide enough features to compare with existing HTTP client libraries
> >> such as Jakarta HttpComponents, so moving it into sandbox might be a
> >> better solution considering that we are going to release MINA 2.0.0-M1
> >> soon and we don't want to release unfinished module.  It also might be
> >> the best idea to cooperate with HttpComponents team to make our
> >> current HTTP codec (i.e. mina-filter-codec-http) and mina-core plug
> >> into HttpComponents NIO extension very easily.  I'd like to know what
> >> the HttpComponents team think about this issue.
> >
> > Trustin, I have a lot more code to contribute in this area as it is
> > currently here:
> >
> > http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient
> >
> > This version contains authentication for Basic, Digest, and NTLM and is
> > much more robust.
> >
> > I am currently working on connection reuse and caching and pooling for
> > those HTTP/1.1 connections that support keep-alives.  I am also working
> > on allowing the NIO socket level attributes to be set as well as client
> > SSL certificate authentication and Proxy Auth capabilities.
> >
> > Jeff
> >
> >
> >> Trustin
>



-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

Posted by Jeff Genender <jg...@apache.org>.
Whoops and forgot to mention...this version also has response timeouts
working as well.

Jeff

Jeff Genender wrote:
> 
> Trustin Lee wrote:
>> 2) I also think mina-protocol-http-client module needs more work to
>> provide enough features to compare with existing HTTP client libraries
>> such as Jakarta HttpComponents, so moving it into sandbox might be a
>> better solution considering that we are going to release MINA 2.0.0-M1
>> soon and we don't want to release unfinished module.  It also might be
>> the best idea to cooperate with HttpComponents team to make our
>> current HTTP codec (i.e. mina-filter-codec-http) and mina-core plug
>> into HttpComponents NIO extension very easily.  I'd like to know what
>> the HttpComponents team think about this issue.
> 
> Trustin, I have a lot more code to contribute in this area as it is
> currently here:
> 
> http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient
> 
> This version contains authentication for Basic, Digest, and NTLM and is
> much more robust.
> 
> I am currently working on connection reuse and caching and pooling for
> those HTTP/1.1 connections that support keep-alives.  I am also working
> on allowing the NIO socket level attributes to be set as well as client
> SSL certificate authentication and Proxy Auth capabilities.
> 
> Jeff
> 
> 
>> Trustin

Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

Posted by Jeff Genender <jg...@apache.org>.

Trustin Lee wrote:
> 2) I also think mina-protocol-http-client module needs more work to
> provide enough features to compare with existing HTTP client libraries
> such as Jakarta HttpComponents, so moving it into sandbox might be a
> better solution considering that we are going to release MINA 2.0.0-M1
> soon and we don't want to release unfinished module.  It also might be
> the best idea to cooperate with HttpComponents team to make our
> current HTTP codec (i.e. mina-filter-codec-http) and mina-core plug
> into HttpComponents NIO extension very easily.  I'd like to know what
> the HttpComponents team think about this issue.

Trustin, I have a lot more code to contribute in this area as it is
currently here:

http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient

This version contains authentication for Basic, Digest, and NTLM and is
much more robust.

I am currently working on connection reuse and caching and pooling for
those HTTP/1.1 connections that support keep-alives.  I am also working
on allowing the NIO socket level attributes to be set as well as client
SSL certificate authentication and Proxy Auth capabilities.

Jeff


> 
> Trustin

Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

Posted by Roland Weber <os...@dubioso.net>.
Hello Trustin,

re-inventing the wheel is never a good thing. To me, it sounds
reasonable that HttpComponents and MINA cooperate on the client
side, at least for the higher level functionality. There is of
course some kind of competition on the lower levels, where
HttpNIO and MINA address similar functionality. IIRC, Oleg had
slightly different design goals for HttpNIO. At the same time,
he made sure that MINA can be used to implement the HttpNIO API.
So yes, I can see potential for joined efforts: higher-level
client functionality like HttpAuth and HttpCookie, and also
a low-level component HttpNIO-on-MINA.

But since Java NIO is not within my sphere of interest,
I have to leave it to others to figure this out (or not).

cheers,
  Roland

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