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). 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. Dave -- View this message in context: http://www.nabble.com/-pre-proposal--AsyncWeb-tf1931092.html#a5360700 Sent from the Apache Incubator - General forum at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
