You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2006/07/31 01:15:44 UTC
HTTP/1.1 server based on HttpComponents Core and MINA
Folks,
Per our discussion and agreement with Peter Royal, I have thrown
together a simple yet full-featured and spec compliant HTTP/1.1 server
based on HttpComponents Core [1] and MINA. My main objective in this
exercise was to see if the HttpComponents protocol layer could be (more
or less) easily put on top of MINA I/O architecture. HttpCore is based
on the classic (blocking) I/O model and I had to use the StreamIoHandler
as a bridge between HttpCore and MINA's event driven I/O model.
The HTTP server appears fully functional and reasonably stable. If
there's an interest in such a contribution I could create a new Jira
ticket and attach the source code to it.
Cheers,
Oleg
[1] http://jakarta.apache.org/httpcomponents/index.html
Re: HTTP/1.1 server based on HttpComponents Core and MINA
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2006-07-31 at 16:32 +0900, Trustin Lee wrote:
> Hi Oleg,
>
> On 7/31/06, Oleg Kalnichevski <ol...@apache.org> wrote:
> >
> > Folks,
> >
> > Per our discussion and agreement with Peter Royal, I have thrown
> > together a simple yet full-featured and spec compliant HTTP/1.1 server
> > based on HttpComponents Core [1] and MINA. My main objective in this
> > exercise was to see if the HttpComponents protocol layer could be (more
> > or less) easily put on top of MINA I/O architecture. HttpCore is based
> > on the classic (blocking) I/O model and I had to use the StreamIoHandler
> > as a bridge between HttpCore and MINA's event driven I/O model.
> >
> > The HTTP server appears fully functional and reasonably stable. If
> > there's an interest in such a contribution I could create a new Jira
> > ticket and attach the source code to it.
>
>
> We're interested definitely! Thank you for your will for contribution!
> Although we need to find out the best way to cooperate with AsyncWeb by
> Dave, but I think we can get advantages from both sides. Great!
>
> Trustin
I am glad to hear that. The first version of the HTTP server based on
Mina and HttpCore is finished and ready for review. However, I would
like to see DIRMINA-229 and DIRMINA-232 issues resolved first, so I
could run a few more tests prior to submitting the code.
Cheers,
Oleg
Re: HTTP/1.1 server based on HttpComponents Core and MINA
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2006-08-01 at 11:41 +0900, Trustin Lee wrote:
> On 8/1/06, peter royal <pr...@apache.org> wrote:
> >
> > On Jul 31, 2006, at 2:21 PM, Irving, Dave wrote:
> > > On the other hand, I believe that there is a huge amount which
> > > asyncweb
> > > can learn from the existing http commons work - for example, I suspect
> > > http commons provides a far more "robust" implementation of the spec -
> > > something Im very keen to work towards.
> >
> > One area in which AsyncWeb can probably leverage http commons stuff
> > would be in cookie and other header parsing. I'm sure there are
> > others as well.
>
>
> Additionally, AsyncWeb is about server and http commons is about client for
> now. I think we can do both side in parallel and see what can be shared
> between them as time goes by, but not right now. It's good to have both
> client and server side, right?
Trustin,
This is not quite the case. HttpCore is generic enough to be used in any
tier: client, proxy or server. It is already used by Apache Axis2 in its
SimpleHttpServer.
This is all it takes to put together a simple HTTP server with HttpCore
http://svn.apache.org/repos/asf/jakarta/httpcomponents/httpcore/trunk/src/examples/org/apache/http/examples/ElementalHttpServer.java
Oleg
>
> Trustin
Re: HTTP/1.1 server based on HttpComponents Core and MINA
Posted by Trustin Lee <tr...@gmail.com>.
On 8/1/06, peter royal <pr...@apache.org> wrote:
>
> On Jul 31, 2006, at 2:21 PM, Irving, Dave wrote:
> > On the other hand, I believe that there is a huge amount which
> > asyncweb
> > can learn from the existing http commons work - for example, I suspect
> > http commons provides a far more "robust" implementation of the spec -
> > something Im very keen to work towards.
>
> One area in which AsyncWeb can probably leverage http commons stuff
> would be in cookie and other header parsing. I'm sure there are
> others as well.
Additionally, AsyncWeb is about server and http commons is about client for
now. I think we can do both side in parallel and see what can be shared
between them as time goes by, but not right now. It's good to have both
client and server side, right?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: HTTP/1.1 server based on HttpComponents Core and MINA
Posted by peter royal <pr...@apache.org>.
On Jul 31, 2006, at 2:21 PM, Irving, Dave wrote:
> On the other hand, I believe that there is a huge amount which
> asyncweb
> can learn from the existing http commons work - for example, I suspect
> http commons provides a far more "robust" implementation of the spec -
> something Im very keen to work towards.
One area in which AsyncWeb can probably leverage http commons stuff
would be in cookie and other header parsing. I'm sure there are
others as well.
-pete
--
proyal@apache.org - http://fotap.org/~osi
RE: HTTP/1.1 server based on HttpComponents Core and MINA
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2006-07-31 at 19:21 +0100, Irving, Dave wrote:
> I've been having a dig around the http components site, but I cant
> really see a clear picture of the goals of http nio.
> Maybe this is because, as you say, all options are still on the table.
> So its not currently clear to me that there is necessarily a large
> amount of overlap. The key principle of asyncweb is not that it uses NIO
> - rather that it is asynchronous in its dispatch through the "container"
> (service, endpoint, whatever you want to call it).
> It is this freedom which makes it useful (scalable) in gateways and
> other (potentially) high latency usage scenarios.
>
I think the overlap between HttpComponents and Asyncweb will be quite
significant. Both projects will end up developing HTTP protocol logic
that sits on top of a lower level I/O model. The only difference between
projects is likely to be the fact that Asyncweb is based on MINA,
whereas HttpComponents strive to be self-contained (no external
dependencies for core components) and adaptable to any I/O model.
HttpComponents will provide primitives for the classic (blocking) I/O
model as well as for the asynchronous, event driven I/O model.
> I believe asyncweb also presents a fairly intuitive asynchronous API, as
> well as making it very easy to drop in IoC configured services and
> manage routing to those services. All of this is already well defined
> and in use today by some other folks (Xfire, Xwire, Glassfish, Restlet
> and possibly Mule in the near future).
> There also seems to be a healthy number of people keen to get involved
> with developing project when it (hopefully) comes to MINA in the near
> future ( http://www.nabble.com/-pre-proposal--AsyncWeb-tf1931092.html ).
>
> For these reasons, I think its worthwhile giving asyncweb a chance to
> grow within Mina and see where we end up.
Fair enough. I understand.
Cheers,
Oleg
RE: HTTP/1.1 server based on HttpComponents Core and MINA
Posted by "Irving, Dave" <da...@logicacmg.com>.
Oleg Kalnichevski wrote:
> Hi Dave,
>
> We (HttpComponents project) have started development of HTTP
> components that utilize HttpCore protocol code on top of an
> event driven I/O model based on NIO. This sub-project is
> presently being referred to as HttpNIO. The name of the
> project may change or its code base may end up merged into
> HttpCore. At this point all options are still on the table.
>
> I do not have an issue with AsyncWeb becoming an Apache
> project and competing with HttpComponents. There are many
> overlapping projects within Apache, so this is nothing really
> new. For instance, HttpComponents project itself overlaps
> with Tomcat Coyote efforts.
> Having said that I urge you to consider as an option of
> contributing HTTP protocol code to HttpComponents HttpNIO and
> building HTTP services in MINA using HttpComponents.
>
> I understand you may not be that thrilled about the idea of
> abandoning AsyncWeb, nonetheless, this still may be a better
> alternative than having two directly competing projects within Apache.
I've been having a dig around the http components site, but I cant
really see a clear picture of the goals of http nio.
Maybe this is because, as you say, all options are still on the table.
So its not currently clear to me that there is necessarily a large
amount of overlap. The key principle of asyncweb is not that it uses NIO
- rather that it is asynchronous in its dispatch through the "container"
(service, endpoint, whatever you want to call it).
It is this freedom which makes it useful (scalable) in gateways and
other (potentially) high latency usage scenarios.
Back in late '05 when I started developing asyncweb, there simply wasn't
anything ("well known", at least) around which gave this functionality
in java. Jetty Continuations was probably the closest ("well known")
thing to it.
So certainly back then, there was definitely no obvious duplication with
http commons.
I believe asyncweb also presents a fairly intuitive asynchronous API, as
well as making it very easy to drop in IoC configured services and
manage routing to those services. All of this is already well defined
and in use today by some other folks (Xfire, Xwire, Glassfish, Restlet
and possibly Mule in the near future).
There also seems to be a healthy number of people keen to get involved
with developing project when it (hopefully) comes to MINA in the near
future ( http://www.nabble.com/-pre-proposal--AsyncWeb-tf1931092.html ).
For these reasons, I think its worthwhile giving asyncweb a chance to
grow within Mina and see where we end up.
On the other hand, I believe that there is a huge amount which asyncweb
can learn from the existing http commons work - for example, I suspect
http commons provides a far more "robust" implementation of the spec -
something Im very keen to work towards.
> Consider this as an invitation to join HttpComponents.
I'd love to join HttpComponents. Im real interested in everything http -
and would love to help out in any small way I can.
> Cheers,
>
> Oleg
Dave
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
RE: HTTP/1.1 server based on HttpComponents Core and MINA
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2006-07-31 at 10:02 +0100, Irving, Dave wrote:
> > We're interested definitely! Thank you for your will for
> > contribution!
> > Although we need to find out the best way to cooperate with
> > AsyncWeb by Dave, but I think we can get advantages from both
> > sides. Great!
>
> This sounds very cool - Im looking forward to checking out the code!
> I would suspect that the commons http stuff is far more "mature" than
> asyncweb in its full http support etc.
> Of course, asyncweb has the event driven model throughout which is very
> useful in router / gateway style apps (b.t.w see
> http://docs.codehaus.org/display/XWIRE/Home for a great example usage).
> So, I think there certainly are advantages from both... It's a very
> exciting time! :o)
Hi Dave,
We (HttpComponents project) have started development of HTTP components
that utilize HttpCore protocol code on top of an event driven I/O model
based on NIO. This sub-project is presently being referred to as
HttpNIO. The name of the project may change or its code base may end up
merged into HttpCore. At this point all options are still on the table.
I do not have an issue with AsyncWeb becoming an Apache project and
competing with HttpComponents. There are many overlapping projects
within Apache, so this is nothing really new. For instance,
HttpComponents project itself overlaps with Tomcat Coyote efforts.
Having said that I urge you to consider as an option of contributing
HTTP protocol code to HttpComponents HttpNIO and building HTTP services
in MINA using HttpComponents.
I understand you may not be that thrilled about the idea of abandoning
AsyncWeb, nonetheless, this still may be a better alternative than
having two directly competing projects within Apache.
Consider this as an invitation to join HttpComponents.
Cheers,
Oleg
>
> I think we're just waiting for the green light, and then asyncweb can
> come to MINA - hopefully very soon :o)
>
> Dave
>
> > Trustin
> > --
> > what we call human nature is actually human habit
> > --
> > http://gleamynode.net/
> > --
> > PGP key fingerprints:
> > * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
> > * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
> >
>
>
> This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
>
RE: HTTP/1.1 server based on HttpComponents Core and MINA
Posted by "Irving, Dave" <da...@logicacmg.com>.
> We're interested definitely! Thank you for your will for
> contribution!
> Although we need to find out the best way to cooperate with
> AsyncWeb by Dave, but I think we can get advantages from both
> sides. Great!
This sounds very cool - Im looking forward to checking out the code!
I would suspect that the commons http stuff is far more "mature" than
asyncweb in its full http support etc.
Of course, asyncweb has the event driven model throughout which is very
useful in router / gateway style apps (b.t.w see
http://docs.codehaus.org/display/XWIRE/Home for a great example usage).
So, I think there certainly are advantages from both... It's a very
exciting time! :o)
I think we're just waiting for the green light, and then asyncweb can
come to MINA - hopefully very soon :o)
Dave
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
>
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Re: HTTP/1.1 server based on HttpComponents Core and MINA
Posted by Trustin Lee <tr...@gmail.com>.
Hi Oleg,
On 7/31/06, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> Folks,
>
> Per our discussion and agreement with Peter Royal, I have thrown
> together a simple yet full-featured and spec compliant HTTP/1.1 server
> based on HttpComponents Core [1] and MINA. My main objective in this
> exercise was to see if the HttpComponents protocol layer could be (more
> or less) easily put on top of MINA I/O architecture. HttpCore is based
> on the classic (blocking) I/O model and I had to use the StreamIoHandler
> as a bridge between HttpCore and MINA's event driven I/O model.
>
> The HTTP server appears fully functional and reasonably stable. If
> there's an interest in such a contribution I could create a new Jira
> ticket and attach the source code to it.
We're interested definitely! Thank you for your will for contribution!
Although we need to find out the best way to cooperate with AsyncWeb by
Dave, but I think we can get advantages from both sides. Great!
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6