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.
