anonymous wrote : 1) A codec is basically an implementation of the ChannelHandler interface. Therefore, HTTP codec classes should be placed in the org.jboss.netty.handler.codec.http package. makes sense anonymous wrote : 2) We should have at least three types: HttpRequest, HttpResponse and HttpMethod. HttpMethod should be an enum of all available HTTP methods like GET, POST, etc. | | HttpRequest and HttpResponse will represent an actual HTTP request and response respectively. They will provide essential getters that are required to implement an HTTP server and client. (We could add some convenience access methods like cookie accessors, but that's another story.) | | According to the HTTP spec, HTTP request and respose share a couple properties such as header, and therefore it would be a better idea to start from a super interface whose name is 'HttpMessage' IMHO. Yes i agree the basic default message shouuld contain things like header, protocol version etc etc. anonymous wrote : 3) There's no need to implement HTTP codec to support large chunk of data directly, which means a HttpRequest.getContent() can just return a complete ChannelBuffer instead of a special stream type. Then we just pass on the buffer in the usual fashion. anonymous wrote : However, Chunked encoding should be supported instead to enable COMET, which will eventually allow us to use HTTP as a connection-oriented socket. (Bill Burke is also interested in this.) Do we need to support this for the first implementation? anonymous wrote : Once, this codec is ready, I think implementing a highly customized HTTP server shouldn't be difficult at all. WDYT? yes, I think if we concentrate on getting the message model complete we can go from there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183756#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...