On 7/17/06, Dave Irving <[EMAIL PROTECTED]> wrote:
Trustin Lee wrote: > > One possibility though could be that MINA HTTP codec provides only encoder > and decoder implementation for HTTP messages and AsyncWeb is built on top > of > it to provide more tighter integration with existing webapp frameworks and > more HTTP-friently asynchronous APIs. Yep, this is just an imagination in > my brain. We can talk about this step by step. > One of the main goals of asyncweb is to provide maximum flexibility when dealing with http services - to satisfy a wide range of usage scenarios. Even though there is still much to do, in the future it will be possible to hook in to all stages of the message reading / writing processes. This allows things like proper (application level) handling of continuation responses, async streaming of large message bodies etc. So I think in the future the asyncweb API is likely to become more generic and flexible to allow the best possible integration with any application requiring high throughput http (e.g, web service frameworks etc).
It makes total sense. I'd love to see everything becomes real, though we need to draw a line between generalization and specialization when we generalize AsyncWeb because MINA already has its role to provide a generic network application framework. Of course, if this is possible to achieve whilst factoring out and building
upon some lower level http codecs, then that would be awseome! I guess the details of such a refactoring will become more obvious over time after we integrate.
Yes, that's my point. We will see as we integrate. I believe this is the Apache way a community grows up healthy, sound and sustainable, like a bottle of great wine. 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
